Systèmes de gestion de bases de données NFP 107 Les techniques du contrôle de concurrence Philippe Rigaux philippe.rigaux@cnam.fr http://idf.pleiad.net/index.php

Contenu du cours Techniques de versionnement Que se passe-t-il quand plusieurs transactions travaillent sur les mêmes données Techniques de verrouillage Les différents types de verrous, et leur impact Algorithme de sérialisabilité Algorithme de verrouillage à deux phases Algorithme de contrôle multiversions

Versionnement Toute transaction en cours a deux choix en permanence: Valider les maj effectuées avec commit Les annuler avec rollback temps T’ lit e Image avant eavant On remplace image après par image avant On peut effacer l’image avant (sûr?) Image après eavant eaprès T modifie eavant en eaprès T annule (rollback)? T valide (commit)? T lit e

Quelques questions (et réponses) Comment une transaction sait-elle si elle doit lire dans l’image avant ou après En mode READ UNCOMMITTED: on lit toujours dans l’image après (lecture sale)! Autres modes: si e est en cours de modification par T, T’ lit dans l’image avant. Peut-on avoir plusieurs versions en cours de modification dans l’image avant? Non! Si T’ veut modifier e (en cours de modification par T) -> T’ en attente (pas d’écriture sale). Quand efface-t-on l’image avant? Dépend du mode ….

Estampillage et cohérence Pour assurer la cohérence, on doit associer une estampille temporelle à chaque version. C’est l’estampille qui permet de gérer la cohérence des lectures L’estampille est le moment du dernier commit Chaque transaction a aussi une estampille NON, en mode REPEATABLE READ et SERIALIZABLE Et s’il existe une transaction estampillée 8? Alors il faut garder plusieurs versions temps OUI, en mode READ (UN)COMMITTED T18’ lit e T18’ lit e T ’’8 lit e Image avant e6avant e14avant Peut-on effacer l’image avant? On estampille la nouvelle version de e Image après e14avant e30après eaprès T23 modifie eavant en eaprès T23 valide à t=30 T23 lit e

Versionnement: conclusion Notions essentielles: image avant, image après Il ne peut y avoir qu’une image après (pas d’écritures concurrentes) On peut préserver plusieurs images avant Lectures cohérentes => travail complexe et coûteux. Exemple, pour T’’8 Lire dans l’image après -> la donnée est en cours de modification. Puis lire dans l’image avant -> elle est estampillée 14, donc pas bon Remonter encore d’un cran -> on trouve e6, OK

Verrouillage Le contrôle de cohérence implique la pose de verrous sur les données lues ou écrites. Verrous partagés (VP): plusieurs VP peuvent être posés simultanément sur une même donnée par plusieurs transactions. Verrous exclusifs (VE): si un seul VE est posé sur une donnée, c’est le seul verrou. Le choix du type de verrou à poser pour chaque opération dépend du mode d’isolation

Pose d’un verrou partagé Une transaction T veut poser un verrou partagé sur une donnée d T doit s’assurer qu’un verrou exclusif n’est pas posé sur d. Si c’est le cas (pas de VE), le verrou peut être posé, quel que soit par ailleurs l’existence d’autres VP sur d. Sinon (un VE existe), T est mis en attente. Très important: quand T est mise en attente, cela concerne toutes les opérations de d.

Pose d’un verrou exclusif Une transaction T veut poser un verrou exclusif sur une donnée d T doit s’assurer qu’aucun verrou n’est posé sur d, quel que soit son type (VE ou VP) Si c’est le cas (pas de verrou), le VE peut être posé. Sinon (un verrou existe), T est mis en attente. Même remarque: quand T est mise en attente, cela concerne toutes les opérations.

Exemples On considère deux transactions, T1 et T2, et deux données x et y. T1 veut poser un VP sur x? T2 veut poser un VE sur y? T1 veut poser un VP sur y? T1 en attente T2 veut poser un VP sur x? T1 T2 x VP y T1 T2 x y T1 T2 x VP y VE T1 T2 x VP y VE en attente VE T1 T2 x VP y VE en attente VE

Caractérisation des exécutions non sérialisables Pour savoir quand et comment poser des verrous, on va caractériser les exécutions non sérialisables. Conflit: deux opérations pi[x] et qj[y] sont en conflit si x = y, i != j, et p ou q est une écriture. r1[x] et r2[x] sont-elles en conflit? r1[x] et w2[x] sont-elles en conflit? r1[x] et w2[y] sont-elles en conflit? r1[x] et w1[x] sont-elles en conflit?

Relation entre les transactions d’une exécution concurrente Soit H une exécution concurrente comprenant plusieurs transactions T1, T2, …, Tn On définit la relation < sur cet ensemble par: T1 < T2 ssi il existe une opération p de T1, q de T2 telles que p et q sont en conflit p apparaît avant q dans l’exécution H.

Exemple Exécution de deux procédures Réservation() Les conflits r1[s]r1[c1] r2[s] r2[c2] w2[s]w2[c2] w1[s]w1[c1] Exemple des mises à jour perdues! Les conflits r1[s] est en conflit avec w2[s] r2[s] est en conflit avec w1[s] w2[s] est en conflit avec w1[s] Donc on a T1 < T2 et T2 < T1 Le graphe de < est cyclique.

Théorème de sérialisabilité Th: une exécution concurrente est sérialisable ssi le graphe de < est acyclique. L’exemple précédent correspond à une exécution non sérialisable. Le contrôle de concurrence (en mode SERIALIZABLE) consiste à s’assurer qu’aucun cycle n’apparaît dans une exécution concurrente. Plusieurs algorithmes. Le plus ancien: algorithme de verrouillage à deux phases (2PL)

Algorithme de verrouillage à deux phases Le protocole est assuré par un scheduler Il se décrit très simplement: Un verrou partagé est posé sur les lectures Un verrou exclusif est posé sur les écritures Les verrous ne sont pas relâchés avant le commit ou le rollback. C’est un protocole dit « pessimiste » qui vise à prévenir les conflits Il est facile de voir que lectures sales et écritures sales sont impossibles.

Exemple de 2PL Soit l’exécution suivante: r1[x]w2[x]w2[y]C2w1[y]C1 Non sérialisable (pourquoi?) Algorithme 2PL: T1 pose un verrou partagé sur x, et lit x T2 tente de poser un verrou exclusif sur x et est mise en attente T1 pose un verrou exclusif sur y, modifie y, et valide T2 est libérée : elle pose un verrou exclusif sur x T2 verrouille et modifie y, puis valide. Finalement: r1[x] w1[y]C1w2[x]w2[y]C2

Interblocages (deadlocks) Inconvénient du 2PL: risque élevé d’interblocage. Exemple des mises à jour perdues: r1[s]r1[c1] r2[s] r2[c2] w2[s]w2[c2] w1[s]w1[c1] T2 même chose: pose des VP sur s et c2 T1 pose un VP sur c1, et lit c1 T2 veut poser un VE sur s: mise en attente! T1 veut poser un VE sur s: mise en attente! T1 pose un VP sur s, et lit s T1 T2 s VP (attente VE) c1 VP c2 T1 T2 s VP VP (attente VE) c1 c2 T1 T2 s VP c1 c2 T1 T2 s c1 c2 T1 T2 s VP c1 c2 T1 T2 s VP c1 c2

Conclusion Ce qu’il faut retenir Les SGBD utilisent un système de versionnement qui permet de préserver l’état de la base sur une durée très longue -> coût important Il ne peut y avoir qu’une version (la dernière) en cours de mise à jour Pour assurer la propriété précédente, les écritures posent toujours un verrou exclusif Les lectures ne posent pas de verrou en général