Utilité d'une transaction en lecture

Suite d'une discussion démarrée par Bardack (petites questions sur le sujet...)

En résumé, certains conseillent d'utiliser une transaction tout le temps, même pour faire une lecture seule, d'autres pensent que ça n'est pas utile...

Mon avis :

Dans un développement d'application web (client léger), je ne vois pas l'intéret d'utiliser une transaction qui à mon sens, sert avant tout à garantir l'intégrité des données pour des mises à jour (sens large) multiples sur une ou plusieurs tables.

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

Je fais partie de ceux qui pensent qu'ils faut utiliser des transactions même pour de la lecture de données.
De toute façon, tout accès vers une base de données se fait dans une transaction. Si on ne la voit pas explicitement, c'est à cause du mode autocommit.

L'intérêt est de protéger ses données contre les modifications extérieures.
Voir :
http://www.developpez.net/forums/sho...=290661&page=6

Bonsoir,

A mon avis, il est même déconseillé d'ouvrir une transaction pour faire uniquement un SELECT...
Un bon SGBDR se doit d'implémenter les propriétés ACID (http://sqlpro.developpez.com/cours/s...dements/#L4.5). J'en déduis qu'une transaction assure la cohérence et la pertinence des données 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 général 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 pénalise les instructions de type UPDATE, INSERT ou DELETE qui sont en général 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

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 même j'en suis certain) sait très bien de quoi il parle.

Ca dépend quand même 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 empêcher un autre utilisateur de faire une modification concurrente.
Mais, ça suppose quand même 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 déconnecté (http), je ne pense pas qu'on s'amuse à sauvegarder une transaction (par exemple dans la session) pour la récupérer au prochain request et continuer... (bien sûr, on pourrait...)

L'idée n'est pas de garder une transaction active longtemps.
L'idée est simplement d'avoir des données cohérentes au sein d'une transaction, qui regrouperait plusieurs lectures.

fr1man +1 !!

C'est même un anti-pattern de conserver une transaction au-delà d'une requête HTTP. Si on veut monter en charge, il faut conserver un minimum de ressources externes, en particulier les connexions...

Salut,

Concernant la nature des lock, ils dépendent 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 montée en charge.

Bref les transactions sont utiles même en lecture afin de ne pas travailler avec des données non commitées.
Autre cas : les non-repeatable reads, cas ou le résultat est différent entre deux selects faisant intervenir les même tables.