http://idf.pleiad.net/index.php

Systèmes de gestion de bases de donnéesNFP 107Les techniques du contrôle de concurrencePhilippe Rigauxphilippe.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 valide (commit)? T annule (rollback)? 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 T18’ lit e T ’’8 lit e T18’ lit e OUI, en mode READ (UN)COMMITTED Image avant e14avant e6avant Peut-on effacer l’image avant? On estampille la nouvelle version de e Image après e14avant eaprès e30aprè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éesx 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?

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] etw2[x]sont-elles en conflit? • r1[x] etw2[y] sont-elles en conflit? • r1[x] etw1[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() • 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érialisablessi 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 unscheduler • 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] T1 veut poser un VE sur s: mise en attente! T1 pose un VP sur c1, et lit c1 T1 pose un VP sur s, et lit s T2 même chose: pose des VP sur s et c2 T2 veut poser un VE sur s: mise en attente!

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

http://idf.pleiad.net/index.php