Gestion de la concurrence

1. Gestion de la concurrence Sur la base de données DB2 Par Benoît Tixier et Jérôme Baudoux http://www.jerome-baudoux.com

2. Sommaire • Introduction • Rappels sur la gestion de la concurrence • Les niveaux d’isolation • Les verrous • Conclusion http://www.jerome-baudoux.com

3. Introduction • Db2 est une base de données utilisant le langage SQL • Elle est la concurrente de par exemple Oracle, PostgreSQL, ou mySQL • Il s’agit d’une solution propriétaire appartenant à IBM • Elle est notamment utilisé en Java où son utilisation est très simplifiée avec le standard Java Data Objects. http://www.jerome-baudoux.com

4. Rappels sur la gestion de la concurrence • La gestion de la concurrence permet de conserver une base de données cohérente dans le cas d’une utilisation multiutilisateurs. • En effet de nombreux problèmes peuvent altérer la cohérence de notre base de données, voyons quelques exemples. http://www.jerome-baudoux.com

5. Rappels sur la gestion de la concurrence • Perte de mise à jour : • Cet événement survient lorsque deux transactions lisent la même donnée et la modifie chacun à leur tour. Exemple : T1 a = lire(A) T2 a = lire(A) T1 ecrire(A,a+10) T2 ecrire(A,a+20) Dans ce cas la modification de T1 a totalement été ignorée. http://www.jerome-baudoux.com

6. Rappels sur la gestion de la concurrence • Lecture douteuse : • Cet événement survient lorsque une transaction lit une valeur qui n’a pas été validée (COMMIT). Exemple : T1 ecrire (A,10) T2 a = lire(A) T1 Rollback La valeur lue par T2 est donc incohérente. http://www.jerome-baudoux.com

7. Rappels sur la gestion de la concurrence • Lecture non répétable : • Cet événement survient lorsque deux lectures successives d’une même donnée renvoie deux valeurs différentes. Cela signifie que la valeur à été changée par une autre transaction en les deux lecteurs, ce qui peut entrainer une incohérence. http://www.jerome-baudoux.com

8. Rappels sur la gestion de la concurrence • Données fantômes : • Cet événement survient lorsque un requête obtient une liste de ligne correspondant à un critère, et obtient une quantité différente de lignes pour ce même critère lors d’une demande successive. Exemple : T1 a = liste les chambres libres d’un hôtel. T2 annule une réservation (libère une chambre) T1 b = liste les chambres libres d’un hôtel. On a donc a ≠ b http://www.jerome-baudoux.com

9. Les niveaux d’isolation • Afin de garantir l’intégrité des données tout en permettant une meilleur concurrence des exécutions chaque transaction possède un niveau d’isolation. • Voici les différents niveaux d’isolations disponibles sous DB2 : • Lecture répétable (Repeatable Read) • Stabilité de lecture (Read Stability) • Stabilité du curseur (Cursor Stability) • Lecture non validée (Uncommitted Read) http://www.jerome-baudoux.com

10. Les niveaux d’isolation • Lecture répétable (Repeatable Read) : • Lors de l’accès à des éléments d’une table, un verrou est posé sur chaque ligne de cette table. • Ceci garanti donc d’éviter les pertes de mises à jour, les lectures douteuses, les lectures non répétables et les données fantômes. http://www.jerome-baudoux.com

11. Les niveaux d’isolation • Lecture répétable (Repeatable Read) : • Exemple : • Dans le cas d’une gestion d’hôtels, si un client consulte toutes les chambres libres entre le 1er et le 15 janvier toutes les chambres seront bloqués, même celles ne correspondant pas à ce critère. • Il sera donc impossible pour un autre client de réserver une chambre. http://www.jerome-baudoux.com

12. Les niveaux d’isolation • Stabilité de lecture (Read Stability) : • Lors de l’accès à des éléments d’une table, un verrou est posé sur chaque ligne correspondant au critère choisi. • Ceci garanti donc d’éviter les pertes de mises à jour, les lectures douteuses, les lectures non répétables mais pas les données fantômes. http://www.jerome-baudoux.com

13. Les niveaux d’isolation • Stabilité de lecture (Read Stability) : • Exemple : • Dans notre cas précédent cela signifie que seuls les chambres disponibles entre les dates voulues seront bloqués. • En conséquence un autre client pourra réserver une chambre pour une date différente. http://www.jerome-baudoux.com

14. Les niveaux d’isolation • Stabilité du curseur (Cursor Stability) : • Lors de l’accès à des éléments d’une table, un verrou est posé sur uniquement sur la ligne consultée. • Ceci garanti donc d’éviter les pertes de mises à jour, les lectures douteuses, mais ni les lectures non répétables ni les données fantômes. http://www.jerome-baudoux.com

15. Les niveaux d’isolation • Stabilité du curseur (Cursor Stability) : • Exemple : • Dans notre cas précédent cela signifie que seuls les chambres étant actuellement consultés par un utilisateur sont bloquées. • Un second utilisateur pourra donc réserver n’importe quelle chambre à l’exception de celle consultée par le premier utilisateur. http://www.jerome-baudoux.com

16. Les niveaux d’isolation • Lecture non validée (Uncommitted Read) : • Lors de l’accès à des éléments d’une table, un verrou est posé sur la table uniquement si une transaction essaye de la supprimer ou de la modifier. • Il est donc possible de rencontrer des pertes de mises à jour, des lectures douteuses, des lectures non répétables et des données fantômes. http://www.jerome-baudoux.com

17. Les niveaux d’isolation • Lecture non validée (Uncommitted Read) : • Exemple : • Dans notre cas précédent cela signifie qu’aucun verrou est posé (à moins que quelqu’un tente de supprimer ou modifier la table, ce qui est n’est pas envisagé dans notre cas). • Un second utilisateur pourra donc réserver n’importe quelle chambre. http://www.jerome-baudoux.com

18. Les verrous • Nous avons vu que DB2 possédais plusieurs niveaux d’isolations définis en fonction de l’utilisation faire de verrous. • Ces verrous ont pour but de contrôler les interactions avec les transactions s’exécrant de façon concurrente. • Un verrou n’est relâché qu’une fois la transaction terminée http://www.jerome-baudoux.com

19. Les verrous • Si une transaction tente d’accéder à une donnée verrouillée il y a deux cas de figure : • Le verrou posé est compatible avec ce que souhaite faire la seconde transactions, auquel cas elle peut s’exécuter. • Dans le cas contraire la seconde transaction doit attendre que le verrou soit relâché. • Cela signifie donc qu’il y a plusieurs types de verrous. http://www.jerome-baudoux.com

20. Les verrous • Intent None (IN) • S’applique sur une ou plusieurs tables. • La transaction peut lire les données de la table mais pas les modifier. • La transaction ne possède aucun verrou sur les lignes donc n’a aucun contrôle sur celles-ci. • N’importe qui peut modifier les données. • Ce verrou correspond à une demande en lecture seule. http://www.jerome-baudoux.com

21. Les verrous • Intent Share (IS) • S’applique sur une ou plusieurs tables. • La transaction peut lire les données de la table mais pas les modifier. • La transaction possède un verrou Share(S) sur les lignes correspondant aux critères. • N’importe qui peut modifier les données. • Ce verrou correspond à une demande en lecture seule. http://www.jerome-baudoux.com

22. Les verrous • Share (S) • S’applique sur une table ou sur une ligne. • La transaction peut lire la donnée boquée. • N’importe qui peut lire les données, mais elles ne sont pas modifiables. • Ce verrou correspond à une demande en lecture seule. http://www.jerome-baudoux.com

23. Les verrous • Next Key Share (NS) • S’applique sur une ligne. • La transaction peut lire la donnée boquée. • N’importe qui peut lire les données, mais elles ne sont pas modifiables. • Ce verrou est utilisé à la place du Share(S) lors d’une isolation Stabilité de lecture (Read Stability) ou Stabilité du curseur (CursorStability) • Ce verrou correspond à une demande en lecture seule. http://www.jerome-baudoux.com

24. Les verrous • Intent Exclusive (IX) • S’applique sur une ou plusieurs tables. • La transaction peut lire et modifier les données. • La transaction obtiens un verrou Share (S) pour chaque ligne qu’elle lis et obtiens un verrou Update (U) et Exclusive (X) sur chaque ligne qu’elle modifie • Les autres transactions peuvent lire et modifier la table. • Ce verrou correspond à une intention de modification. Transactions de type SELECT contenant FOR UPDATE http://www.jerome-baudoux.com

25. Les verrous • Share With Intent Exclusive (SIX) • S’applique sur une table. • La transaction peut lire et modifier les données. • La transaction obtiens un verrou Exclusive (X) sur chaque ligne qu’elle modifie, mais pas de verrou sur les lignes lue • Les autres transactions peuvent lire mais pas modifier les données. • Ce verrou correspond à une intention de modification. http://www.jerome-baudoux.com

26. Les verrous • Update (U) • S’applique sur une table ou ligne. • La transaction peut modifier les données les données. • La transaction obtiens un verrou Exclusive (X) sur chaque ligne qu’elle modifie. • Les autres transactions peuvent lire mais pas modifier les données. • Ce verrou correspond à une intention de modification. http://www.jerome-baudoux.com

27. Les verrous • Next Key Exclusive (NX) / Next Key Weak Exclusive (NW) • S’applique sur une ligne. • La transaction peut lire mais pas modifier les données. • La transaction obtiens ce verrou lorsqu’une ligne a été supprimée. • Ces verrous sont utilisé à la place du Exclusive(X) lors d’une isolation Stabilité de lecture (Read Stability) ou Stabilité du curseur (Cursor Stability) http://www.jerome-baudoux.com

28. Les verrous • Exclusive (X) • S’applique sur une table ou ligne. • La transaction peut lire et modifier les données. • Seul les transactions utilisant une isolation de type Lecture non validée (Uncommitted Read) peuvent lire les données. • Ce verrou correspond à une demande de modification (INSERT, UPDATE, ou DELETE ) http://www.jerome-baudoux.com

29. Les verrous • Weak Exclusive (WE) • S’applique sur une ligne. • La transaction peut lire et modifier les données. • Seul les transactions utilisant une isolation de type Lecture non validée (Uncommitted Read) peuvent lire les données. • Ce verrou est utilisé lors de l’ajout d’une ligne dans un table. http://www.jerome-baudoux.com

30. Les verrous • Super Exclusive (Z) • S’applique sur une ligne. • La transaction peut modifier la table, la supprimer, ajouter un supprimer un index. • Aucune exécution concurrente n’est autorisée. • Ce verrou est utilisé lors des appels à DROP TABLE, et ALTER TABLE http://www.jerome-baudoux.com

31. Les verrous • Conversion de verrou • Il peut arriver qu’une transaction possédant un verrou sur une ressource demande un nouveau verrou plus restrictif. • Etant donné qu’une transaction ne peut posséder qu’un verrou par ressource, le verrou est automatiquement transformé pour correspondre aux besoins. http://www.jerome-baudoux.com

32. Les verrous • Conversion de verrou • Exemple : • T1 possède un verrou Share(S) sur un ligne. • T1 souhaite modifier la donnée • T1 demande un verrou de type Eclusive(X) • Le verrou Share(S) est transformé en Exclusive(X) http://www.jerome-baudoux.com

33. Les verrous • Augmentation du nombre de verrous • DB2 maximise la pose de verrou sur des lignes. Une pose de plusieurs verrous de type ligne permettant plus de concurrence qu’un unique verrou sur une table, les performance s’en trouve améliorées. (L’utilisateur peut toutefois décider de poser explicitement un verrou sur une table plutôt que sur plusieurs lignes) • Le problème de cette méthode est le nombre important de verrous qui peuvent être distribué. Un verrou ayant un coup mémoire, ils ne sont pas infinis. http://www.jerome-baudoux.com

34. Les verrous • Augmentation du nombre de verrous • Que faire si il n’y a plus assez de place pour poser un nouveau verrou ? • DB2 va dans ce cas convertir des verrous lignes en verrous tables afin d’en réduire le nombre. • Si ceci est impossible, la transaction est alors refusée. http://www.jerome-baudoux.com

35. Les verrous • Les inter-blocages • Le choix de DB2 pour gérer les inter-blocages et la mise en place d’un détecteur. • Celui-ci est la plus part du temps endormi et se réveille à une fréquence défini afin de déterminer si il y a inter-blocage. Si un inter-blocage est détecté il choisi une transaction et lui demande d’effectuer un rollback. http://www.jerome-baudoux.com

36. Les verrous • Les timeouts • Il est possible de préciser le temps maximum d’attente avant l’obtention d’un verrou. • Si celui-ci n’a pas été libéré dans les temps, la transaction est annulée. http://www.jerome-baudoux.com

37. Conclusion • DB2 fourni donc à l’utilisateur des outils pour gérer le degré de concurrence et d’isolation en fonction de ces besoins. • Ceci permet donc tout en maintenant une base de donnée cohérente, de maximiser les exécutions concurrentes. • Une grande partie de ces comportements est automatisé mais peuvent être laissé à la discrétion de l’utilisateur. http://www.jerome-baudoux.com