[Spring] Comprendre le fonctionnement de l'attribut d'isolation des transactions

 Introduction

Lorsque plusieurs transactions d'une même application ou de différentes applications fonctionnent simultanément sur le même jeu de données, cela peut entraîner de nombreux problèmes inattendus. Pour résoudre ces problèmes, il est essentiel de spécifier comment vous souhaitez que vos transactions soient isolées les unes des autres. C'est là qu'intervient l'attribut d'isolation des transactions. Dans cet article, nous allons explorer comment cet attribut fonctionne et comment il peut résoudre les problèmes courants liés aux transactions concurrentes.

https://www.baeldung.com/spring-transactional-propagation-isolation#transactional-isolations 

Problème

Les transactions concurrentes peuvent provoquer quatre types de problèmes :

Lecture sale (Dirty read) : Dans ce scénario, deux transactions, T1 et T2, sont en cours. T1 lit un champ qui a été mis à jour par T2 mais qui n'a pas encore été validé. Si T2 est annulée ultérieurement, la valeur lue par T1 deviendra temporaire et invalide.

Lecture non répétable (Nonrepeatable read) : Ici, T1 lit un champ, puis T2 met à jour ce champ. Si T1 lit à nouveau ce champ, la valeur sera différente de ce qu'elle était précédemment.

Lecture fantôme (Phantom read) : Dans ce cas, T1 lit certaines lignes d'une table, puis T2 insère de nouvelles lignes dans cette table. Lorsque T1 lit à nouveau la même table, il y aura des lignes supplémentaires auxquelles il n'avait pas accès précédemment.

Pertes de mises à jour (Lost updates) : T1 et T2 sélectionnent tous deux une ligne à mettre à jour et, en fonction de l'état de cette ligne, effectuent une mise à jour. Ainsi, l'une écrase l'autre alors que la deuxième transaction aurait dû attendre que la première soit validée avant de procéder à sa sélection.

Solution

En théorie, les transactions devraient être complètement isolées les unes des autres (c'est-à-dire sérialisables) pour éviter tous les problèmes mentionnés ci-dessus. Cependant, ce niveau d'isolation aurait un impact considérable sur les performances, car les transactions devraient s'exécuter dans un ordre séquentiel strict. Dans la pratique, il est possible de faire fonctionner les transactions à des niveaux d'isolation inférieurs afin d'améliorer les performances.

L'attribut d'isolation des transactions permet de définir le niveau d'isolation souhaité pour une transaction donnée. Les niveaux d'isolation couramment utilisés incluent :

Isolation de lecture non répétable (Read Uncommitted) : Dans ce niveau, aucune isolation n'est garantie. Les transactions peuvent lire des données non validées par d'autres transactions en cours, ce qui peut entraîner des problèmes de lecture sale, de lecture non répétable et de pertes de mises à jour.

Isolation de lecture répétable (Read Committed) : Ce niveau permet d'éviter les lectures sales, mais les problèmes de lecture non répétable et de pertes de mises à jour peuvent toujours survenir.

Isolation de répétition de lecture (Repeatable Read) : Ce niveau résout les problèmes de lecture non répétable en garantissant que toutes les données lues par une transaction restent constantes jusqu'à la fin de cette transaction. Cependant, les lectures fantômes peuvent toujours se produire.

Isolation sérialisable (Serializable) : C'est le niveau le plus strict, garantissant une isolation totale. Cependant, cela peut avoir un impact significatif sur les performances, car les transactions doivent s'exécuter de manière séquentielle.

Conclusion

L'attribut d'isolation des transactions est un outil essentiel pour gérer les problèmes liés aux transactions concurrentes. En comprenant les différents niveaux d'isolation disponibles et en choisissant celui qui convient le mieux à vos besoins, vous pouvez garantir que vos transactions fonctionnent de manière fiable tout en optimisant les performances de votre système. Il est important de peser soigneusement les avantages et les inconvénients de chaque niveau d'isolation pour prendre la décision la plus appropriée en fonction de votre application et de vos exigences.

NB :
La gestion de l'isolation des transactions dépend de la capacité du moteur de base de données sous-jacent à prendre en charge différents niveaux d'isolation. Les applications et les frameworks n'ont généralement pas un contrôle direct sur la gestion de l'isolation des transactions, mais ils peuvent interagir avec le moteur de base de données pour spécifier le niveau d'isolation souhaité.