# Java > Gnral Java > Persistance des donnes >  Utilit d'une transaction en lecture

## OButterlin

Suite d'une discussion dmarre par Bardack (petites questions sur le sujet...)

En rsum, certains conseillent d'utiliser une transaction tout le temps, mme pour faire une lecture seule, d'autres pensent que a n'est pas utile... 

Mon avis :

Dans un dveloppement d'application web (client lger), je ne vois pas l'intret d'utiliser une transaction qui  mon sens, sert avant tout  garantir l'intgrit des donnes pour des mises  jour (sens large) multiples sur une ou plusieurs tables.

On en tait l, vos commentaires sont les bienvenus...

----------


## fr1man

Je fais partie de ceux qui pensent qu'ils faut utiliser des transactions mme pour de la lecture de donnes.
De toute faon, tout accs vers une base de donnes se fait dans une transaction. Si on ne la voit pas explicitement, c'est  cause du mode autocommit.

L'intrt est de protger ses donnes contre les modifications extrieures.
Voir :
http://www.developpez.net/forums/sho...=290661&page=6

----------


## elzedo

Bonsoir,

A mon avis, il est mme dconseill d'ouvrir une transaction pour faire uniquement un SELECT... 
Un bon SGBDR se doit d'implmenter les proprits ACID (http://sqlpro.developpez.com/cours/s...dements/#L4.5). J'en dduis qu'une transaction assure la cohrence et la pertinence des donnes d'une suite d'instructions SQL.

Il y a aussi une histoire de verrous partag et exclusif... Je ne sais pas si c'est le cas de tous les serveurs, mais en gnral lors d'un SELECT en dehors d'une transaction, le moteur SGBDR pose un verrou partag alors que pour un UPDATE, un INSERT ou un DELETE, il pose un verou exclusif sur l'enregistrement. Du coup, s'il y a un SELECT alors qu'un verrou exculif est pos sur l'enregistrement, il devra attendre que le verrou se termine.

A l'inverse, si l'on utilise une transaction juste pour faire un SELECT, ce qui  mon avis est inutile, on pnalise les instructions de type UPDATE, INSERT ou DELETE qui sont en gnral importantes. Sur un site transactionnel (marchand ^^) qui enregistre plusieurs centaines ou milliers d'utilisateurs, a ne serait pas permis. Je parle en connaissance de cause...

++
Laurent

----------


## fr1man

http://forum.hibernate.org/viewtopic...098&highlight=

Va voir ce lien, o il y a une petite explication d'un des membres de l'quipe d'Hibernate, qui je pense (et mme j'en suis certain) sait trs bien de quoi il parle.

----------


## OButterlin

Ca dpend quand mme du type d'application qu'on crit.

J'arrive  comprendre l'utilisation d'une transaction pour une lecture en vue de modification, dans le cas o on veut empcher un autre utilisateur de faire une modification concurrente.
Mais, a suppose quand mme qu'on maintient la transaction active jusqu'au commit/rollback final.

C'est l que le type d'application intervient : pour une appli web, en mode dconnect (http), je ne pense pas qu'on s'amuse  sauvegarder une transaction (par exemple dans la session) pour la rcuprer au prochain request et continuer... (bien sr, on pourrait...)

----------


## fr1man

L'ide n'est pas de garder une transaction active longtemps.
L'ide est simplement d'avoir des donnes cohrentes au sein d'une transaction, qui regrouperait plusieurs lectures.

----------


## xv-mnt

fr1man +1 !!

C'est mme un anti-pattern de conserver une transaction au-del d'une requte HTTP. Si on veut monter en charge, il faut conserver un minimum de ressources externes, en particulier les connexions...

----------


## grishka

Salut,

Concernant la nature des lock, ils dpendent du niveau d'isolation de la transaction. Cf http://en.wikipedia.org/wiki/Isolati...puter_science). Le plus exigeant tant serializable, qui supporte le moins la monte en charge.

Bref les transactions sont utiles mme en lecture afin de ne pas travailler avec des donnes non commites.
Autre cas : les non-repeatable reads, cas ou le rsultat est diffrent entre deux selects faisant intervenir les mme tables.

----------

