gestion de la concurrence

Sur la base de données DB2

Par Benoît Tixier et Jérôme Baudoux

1http://www.jerome-baudoux.com

Sommaire

IntroductionRappels sur la gestion de la concurrenceLes niveaux d’isolationLes verrousConclusion


IntroductionDb2 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.


Rappels sur la gestion de la concurrenceLa 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.


Rappels sur la gestion de la concurrencePerte 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.


Rappels sur la gestion de la concurrenceLecture 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.


Rappels sur la gestion de la concurrenceLecture 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.


Rappels sur la gestion de la concurrenceDonné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


Les niveaux d’isolationAfin 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)


Les niveaux d’isolationLecture 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.


Les niveaux d’isolationLecture 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.


Les niveaux d’isolationStabilité 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.


Les niveaux d’isolationStabilité 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.


Les niveaux d’isolationStabilité 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.


Les niveaux d’isolationStabilité 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.


Les niveaux d’isolationLecture 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.


Les niveaux d’isolationLecture 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.


Les verrousNous 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


Les verrousSi 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.


Les verrousIntent 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.


Les verrousIntent 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.



Les verrousShare (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.



Les verrousNext 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 (Cursor Stability)



Les verrousIntent 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


Les verrousShare 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.


Les verrousUpdate (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.


Les verrousNext 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)


Les verrousExclusive (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 )


Les verrousWeak 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.


Les verrousSuper 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


Les verrousConversion 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.


Les verrousConversion 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)


Les verrousAugmentation 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.


Les verrousAugmentation 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.


Les verrousLes 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.


Les verrousLes 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.


ConclusionDB2 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.


gestion de la concurrence

Documents