Gestion%20de%20la%20concurrence

1
Gestion de la concurrence

• Sur la base de données DB2
• Par Benoît Tixier et Jérôme Baudoux

2
Sommaire

• Introduction
• Rappels sur la gestion de la concurrence
• Les niveaux disolation
• Les verrous
• Conclusion

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 sagit dune 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.

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 dune
  utilisation multiutilisateurs.
• En effet de nombreux problèmes peuvent altérer la
  cohérence de notre base de données, voyons
  quelques exemples.

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,a10)
• T2 ecrire(A,a20)
• Dans ce cas la modification de T1 a totalement
  été ignorée.

6
Rappels sur la gestion de la concurrence

• Lecture douteuse
• Cet événement survient lorsque une transaction
  lit une valeur qui na 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.

7
Rappels sur la gestion de la concurrence

• Lecture non répétable
• Cet événement survient lorsque deux lectures
  successives dune 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.

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 dune demande successive.
• Exemple
• T1 a liste les chambres libres dun hôtel.
• T2 annule une réservation (libère une chambre)
• T1 b liste les chambres libres dun hôtel.
• On a donc a ? b

9
Les niveaux disolation

• Afin de garantir lintégrité des données tout en
  permettant une meilleur concurrence des
  exécutions chaque transaction possède un niveau
  disolation.
• Voici les différents niveaux disolations
  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)

10
Les niveaux disolation

• Lecture répétable (Repeatable Read)
• Lors de laccès à des éléments dune 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.

11
Les niveaux disolation

• Lecture répétable (Repeatable Read)
• Exemple
• Dans le cas dune gestion dhô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.

12
Les niveaux disolation

• Stabilité de lecture (Read Stability)
• Lors de laccès à des éléments dune 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.

13
Les niveaux disolation

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

14
Les niveaux disolation

• Stabilité du curseur (Cursor Stability)
• Lors de laccès à des éléments dune 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.

15
Les niveaux disolation

• 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
  nimporte quelle chambre à lexception de celle
  consultée par le premier utilisateur.

16
Les niveaux disolation

• Lecture non validée (Uncommitted Read)
• Lors de laccès à des éléments dune 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.

17
Les niveaux disolation

• Lecture non validée (Uncommitted Read)
• Exemple
• Dans notre cas précédent cela signifie quaucun
  verrou est posé (à moins que quelquun tente de
  supprimer ou modifier la table, ce qui est nest
  pas envisagé dans notre cas).
• Un second utilisateur pourra donc réserver
  nimporte quelle chambre.

18
Les verrous

• Nous avons vu que DB2 possédais plusieurs niveaux
  disolations définis en fonction de lutilisation
  faire de verrous.
• Ces verrous ont pour but de contrôler les
  interactions avec les transactions sexécrant de
  façon concurrente.
• Un verrou nest relâché quune fois la
  transaction terminée

19
Les verrous

• Si une transaction tente daccé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 sexécuter.
• Dans le cas contraire la seconde transaction doit
  attendre que le verrou soit relâché.
• Cela signifie donc quil y a plusieurs types de
  verrous.

20
Les verrous

• Intent None (IN)
• Sapplique 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 na aucun contrôle sur celles-ci.
• Nimporte qui peut modifier les données.
• Ce verrou correspond à une demande en lecture
  seule.

21
Les verrous

• Intent Share (IS)
• Sapplique 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.
• Nimporte qui peut modifier les données.
• Ce verrou correspond à une demande en lecture
  seule.

22
Les verrous

• Share (S)
• Sapplique sur une table ou sur une ligne.
• La transaction peut lire la donnée boquée.
• Nimporte qui peut lire les données, mais elles
  ne sont pas modifiables.
• Ce verrou correspond à une demande en lecture
  seule.

23
Les verrous

• Next Key Share (NS)
• Sapplique sur une ligne.
• La transaction peut lire la donnée boquée.
• Nimporte qui peut lire les données, mais elles
  ne sont pas modifiables.
• Ce verrou est utilisé à la place du Share(S) lors
  dune isolation Stabilité de lecture (Read
  Stability) ou Stabilité du curseur (Cursor
  Stability)
• Ce verrou correspond à une demande en lecture
  seule.

24
Les verrous

• Intent Exclusive (IX)
• Sapplique sur une ou plusieurs tables.
• La transaction peut lire et modifier les données.
• La transaction obtiens un verrou Share (S) pour
  chaque ligne quelle lis et obtiens un verrou
  Update (U) et Exclusive (X) sur chaque ligne
  quelle modifie
• Les autres transactions peuvent lire et modifier
  la table.
• Ce verrou correspond à une intention de
  modification. Transactions de type SELECT
  contenant FOR UPDATE

25
Les verrous

• Share With Intent Exclusive (SIX)
• Sapplique sur une table.
• La transaction peut lire et modifier les données.
• La transaction obtiens un verrou Exclusive (X)
  sur chaque ligne quelle 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.

26
Les verrous

• Update (U)
• Sapplique 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 quelle modifie.
• Les autres transactions peuvent lire mais pas
  modifier les données.
• Ce verrou correspond à une intention de
  modification.

27
Les verrous

• Next Key Exclusive (NX) / Next Key Weak Exclusive
  (NW)
• Sapplique sur une ligne.
• La transaction peut lire mais pas modifier les
  données.
• La transaction obtiens ce verrou lorsquune ligne
  a été supprimée.
• Ces verrous sont utilisé à la place du
  Exclusive(X) lors dune isolation Stabilité de
  lecture (Read Stability) ou Stabilité du curseur
  (Cursor Stability)

28
Les verrous

• Exclusive (X)
• Sapplique 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 )

29
Les verrous

• Weak Exclusive (WE)
• Sapplique 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 lajout dune ligne
  dans un table.

30
Les verrous

• Super Exclusive (Z)
• Sapplique sur une ligne.
• La transaction peut modifier la table, la
  supprimer, ajouter un supprimer un index.
• Aucune exécution concurrente nest autorisée.
• Ce verrou est utilisé lors des appels à DROP
  TABLE, et ALTER TABLE

31
Les verrous

• Conversion de verrou
• Il peut arriver quune transaction possédant un
  verrou sur une ressource demande un nouveau
  verrou plus restrictif.
• Etant donné quune transaction ne peut posséder
  quun verrou par ressource, le verrou est
  automatiquement transformé pour correspondre aux
  besoins.

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)

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 quun unique
  verrou sur une table, les performance sen trouve
  améliorées. (Lutilisateur 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.

34
Les verrous

• Augmentation du nombre de verrous
• Que faire si il ny a plus assez de place pour
  poser un nouveau verrou ?
• DB2 va dans ce cas convertir des verrous lignes
  en verrous tables afin den réduire le nombre.
• Si ceci est impossible, la transaction est alors
  refusée.

35
Les verrous

• Les inter-blocages
• Le choix de DB2 pour gérer les inter-blocages et
  la mise en place dun 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 deffectuer un
  rollback.

36
Les verrous

• Les timeouts
• Il est possible de préciser le temps maximum
  dattente avant lobtention dun verrou.
• Si celui-ci na pas été libéré dans les temps, la
  transaction est annulée.

37
Conclusion

• DB2 fourni donc à lutilisateur des outils pour
  gérer le degré de concurrence et disolation 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 lutilisateur.