S´erialisation des transactions
Version 1.2
Vincent Englebert
2007
Contents
1 M´ethodes optimistes 2
1.1 Phase de lecture ...
1 M´ethodes optimistes
Ces m´ethodes d´ecoupent la r´ealisation d’une transaction en trois phases: lecture, vali-
dation e...
1.3 Phase d’´ecriture
Les op´erations d’´ecritures enregistr´ees dans le journal WT sont alors rendues d´efinitives
et visi...
L V E
L V E
L V E
L V E
L V ERecouvrement interdit
Remarque 1 Il est possible que l’ordre des ´ecritures ne soit pas respe...
1.5 Validation backward
Soit Ti une transaction qui rentre dans sa phase de validation. Une fa¸con de v´erifier
l’absence d...
1.6 La validation Forward
Lors de la validation Forward, la transaction en cours de validation (T), compare son
jeu d’´ecr...
2 S´erialisation par estampillage
Le principe de cette technique est d’attribuer un num´ero d’ordre au d´ebut de chaque
tr...
Les diagrammes suivants illustrent respectivement divers sc´enarios pouvant se pro-
duire lors de la lecture et de l’´ecri...
• Illustrer par un ou plusieurs diagrammes les cas repris dans les deux algo-
rithmes.
• Montrer comment cette technique p...
Prochain SlideShare
Chargement dans…5
×

Sérialisation des transactions

1 152 vues

Publié le

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 152
Sur SlideShare
0
Issues des intégrations
0
Intégrations
878
Actions
Partages
0
Téléchargements
2
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Sérialisation des transactions

  1. 1. S´erialisation des transactions Version 1.2 Vincent Englebert 2007 Contents 1 M´ethodes optimistes 2 1.1 Phase de lecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Phase de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Phase d’´ecriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 D´etails de la phase de validation . . . . . . . . . . . . . . . . . . . . . . 3 1.5 Validation backward . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.6 La validation Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2 S´erialisation par estampillage 7 • Ces mat´eriaux p´edagogiques devenus obsol`etes dans notre cursus sont distribu´es en l’´etat et ne sont plus maintenus. • Tout emprunt vers d’autres supports respectera les conditions de la licence Cre- ative Commons Attribution – pas d’utilisation commerciale et partage dans les mˆemes conditions 4.0 International en r´ef´eren¸cant: Source: Universit´e de Namur Belgique - Facult´e d’informatique - V. Englebert • Si jamais, une information ´etait incorrectement r´ef´erenc´ee dans ce document, les ayants-droits sont pri´es de me contacter afin de corriger le document: vin- cent.englebert (at) unamur.be 1
  2. 2. 1 M´ethodes optimistes Ces m´ethodes d´ecoupent la r´ealisation d’une transaction en trois phases: lecture, vali- dation et ´ecriture. 1.1 Phase de lecture Le lancement d’une transaction commence en phase de lecture. Les op´erations de lecture et d’´ecriture de donn´ees s’effectuent normalement sans restrictions. Cependant, elles sont red´efinies comme suit: On note T la transaction en cours. Procedure Write’(X,V ) begin WT := WT X → V ; end Function Read’(X)→ V begin if WT (X) = undef then V := read(X) else V := WT (X); end La red´efinition des op´erations ´el´ementaires d’acc`es aux donn´ees permet: 1. D’´eviter de modifier l’´etat effectif des donn´ees. En effet, les ´ecritures sont enreg- istr´ees dans un journal propre `a chaque transaction (i.e., WT ). 2. La lecture d’une donn´ee retourne soit une valeur qui a fait l’objet d’une conclusion (commit) d’une pr´ec´edente transaction ou de la derni`ere ´ecriture au sein de cette mˆeme transaction. 3. Chaque transaction peut avoir des valeurs diff´erentes pour une mˆeme donn´ee. 4. Enfin, le lecteur distrait remarquera que cette phase (contrairement `a son nom), n’empˆeche pas les tentatives d’´ecritures! 1.2 Phase de validation La phase de validation commence lorsque la demande de clˆoture de transaction est ´emise par le client. Une validation aposteriori est alors effectu´ee afin de rep´erer l’existence d’un conflit avec des transactions qui se seraient clˆotur´ees dans le mˆeme intervalle de temps. Si tout conflit est ´evit´e, alors on passe `a la phase suivante. La phase de validation sera d´etaill´ee ci-apr`es. 2
  3. 3. 1.3 Phase d’´ecriture Les op´erations d’´ecritures enregistr´ees dans le journal WT sont alors rendues d´efinitives et visibles pour les autres transactions en cours et `a venir. La transaction se clˆoture d`es qu’elle a obtenu l’assurance que toutes les donn´ees ont ´et´e sauvegard´ees en lieu sˆur. 1.4 D´etails de la phase de validation Chaque transaction re¸coit un num´ero lorsqu’elle rentre dans la phase de validation. On num´erotera donc les transactions T1, T2, . . . , Tn et on notera Ti ≤ Tj si i ≤ j. `A la fin de la phase de validation, • soit la transaction est valid´ee, et son son num´ero est d´efinitif; • soit la transaction est invalid´ee, et son num´ero est lib´er´e; • soit la transaction n’a proc´ed´e `a aucune modification (elle n’a fait que des lectures de donn´ees — WT = ∅), et alors son num´ero est ´egalement lib´er´e. Lorsqu’un num´ero est lib´er´e, celui-ci devient `a nouveau disponible pour une autre transaction. Les transactions se voient attribuer un num´ero de transaction croissant (cfr. exclusion des phases expliqu´ees ci-apr`es). Propri´et´e Si Ti < Tj, alors la phase de lecture de Ti se termine avant le d´ebut de la phase de validation de Tj. Pour qu’une transaction A soit s´erialisable avec une transaction B, il suffit1 que: 1. A ne lise pas des donn´ees modifi´ees par B; 2. B ne lise pas des donn´ees modifi´ees par A; 3. A ne modifie pas des donn´ees modifi´ees par B; et 4. B ne modifie pas des donn´ees modifi´ees par A. Dans les faits, les phases de validation et d’´ecriture durent tr`es peu de temps lorsqu’on les compare `a la phase de lecture qui comprend tout le “business” de la transaction. On peut donc rendre les s´equences [ validation — ´ecriture] de diff´erentes transactions exclusives entre elles. L’ensemble de ces deux phases forme donc une section critique atomique et exclusive avec toute autre s´equence. La validation ne doit donc v´erifier que les deux premi`eres r`egles. 1 Mais ces conditions ne sont pas n´ecessaires, on peut ais´ement imaginer deux transactions X ← 1 et X ← 1 qui modifient la mˆeme donn´ee mais restent dans ce cas bien pr´ecis tout `a fait s´erialisables. 3
  4. 4. L V E L V E L V E L V E L V ERecouvrement interdit Remarque 1 Il est possible que l’ordre des ´ecritures ne soit pas respect´e par les phases d’´ecriture. Temps Transaction A Transaction B 1 Write’(X,1) 2 Write’(X,2) 3 Validation 4 Write(X,2) 5 Validation 6 Write(X,1) Remarque 2 Si deux transactions Ti et Tj ont ´et´e clˆotur´ees et que Ti < Tj, alors on est certain que Ti a ´et´e clˆotur´ee avant Tj grˆace au principe d’exclusion des phases. 4
  5. 5. 1.5 Validation backward Soit Ti une transaction qui rentre dans sa phase de validation. Une fa¸con de v´erifier l’absence de conflits (i.e., v´erifier les r`egles 1 et 2), est de s’assurer que les donn´ees lues par Ti n’ont pas ´et´e modifi´ees par une autre transaction qui aurait conclu sa phase d’´ecriture durant la phase de lecture de Ti. Soit P le plus grand num´ero de transaction affect´e `a une transaction clˆotur´ee∗ lorsque la transaction Ti entame sa phase de lecture. Soit Q, le plus grand num´ero de transaction clˆotur´ee∗ lorsque la transaction Ti entame sa phase de validation. Alors l’algorithme de validation peut ˆetre d´ecrit comme suit: ∗Ces trans- actions sont n´ecessairement clˆotur´ees. Parmi les options 1, 2 et 3 de cet algorithme, quelle est celle qui correspond `a la description pr´ec´edente ? Function Validation(T)→ Boolean begin 1) r := ∃i ∈ N : (P + 1 ≤ i ≤ Q) ∧ (RT ∩ dom(WTi ) = ∅); 2) r := ∃i ∈ N : (P + 1 ≤ i ≤ Q) ∧ (RT ∩ dom(WT ) = ∅); 3) r := ∀i ∈ N : (P + 1 ≤ i ≤ Q) ∧ (RT ∩ dom(WTi ) = ∅); return ¬r; end #T :=15 ]12 ]13 ]14 [ ]11 [ [ [ [ ]15 Sur le sch´ema pr´ec´edent, P et Q valent respectivement 12 et 14. La transaction courante se voit attribuer le num´ero 15 au d´ebut de sa phase de validation. Question Montrez que les transactions ne comportant que des instructions d’´ecriture ne posent jamais de probl`emes lors de la validation. La validation backward impose au moniteur de transactions de garder les tentatives d’´ecritures des transactions qui recouvrent une transaction en cours (cfr. les WTx ). Cet effort peut ˆetre cons´equent lorsque les transactions durent longtemps. 5
  6. 6. 1.6 La validation Forward Lors de la validation Forward, la transaction en cours de validation (T), compare son jeu d’´ecritures avec les jeux de lectures des autres transactions actives2 . Comme ces transactions n’ont pas encore entam´e leur phase de validation, elles n’ont pas re¸cu de num´ero de transaction. Nous d´esignerons par A1, . . . , An l’ensemble des transactions qui ont d´emarr´e leur phase de lecture pendant l’ex´ecution de la transaction T et qui n’ont pas ´et´e clˆotur´ees entretemps. L’algorithme de validation peut ˆetre d´ecrit comme suit: Fonction Validation(T)→ Boolean begin r := ∀i ∈ [1, . . . , n] : dom(WT ) ∩ RAi = ∅; return r; end ´Etant donn´e qu’il n’y a pas d’exclusion entre les phases de lecture des transactions Ai et la phase de validation de T, l’algorithme de validation prendra en compte le fait que les ensembles RAi peuvent changer au cours du calcul! Lorsqu’un conflit survient, plusieurs strat´egies peuvent ˆetre envisag´ees. Soit Ak une transaction qui rentre en conflit avec T. 1. On laisse tomber la validation de T (→ le num´ero de transaction de T redevient disponible). Cela permettra peut-ˆetre `a Ak de se clˆoturer, et donc la cause du conflit peut ´eventuellement disparaˆıtre. Avantage Dans le meilleur des cas, on n’avorte aucune transaction. Cette solution pr´eserve donc les acquis. Inconv´enient une autre transaction peut survenir en cours de temps et ren- trer en conflit avec T. La validation de T serait donc encore suspendue. On peut imaginer un sc´enario o`u T ne serait jamais clˆotur´ee. 2. On avorte toutes les transactions actives qui posent probl`eme et on clˆoture T. 3. On avorte T. Dans les strat´egies o`u une transaction est avort´ee, le client est inform´e de l’´echec et doit donc relancer sa transaction. Mais le client n’a toutefois pas la garantie que sa transaction aura plus de chances les prochaines fois. 2 Elles sont donc dans la phase de lecture. 6
  7. 7. 2 S´erialisation par estampillage Le principe de cette technique est d’attribuer un num´ero d’ordre au d´ebut de chaque transaction et de s’assurer lors des op´erations de lecture et ´ecriture que deux transac- tions Ti et Tj se comportent comme si Tj s’ex´ecutait apr`es Ti si i < j. Cette technique attribue une num´ero (par exemple le temps) `a chaque transaction d`es son d´ebut3 . Chaque donn´ee D poss`ede deux ensembles DW et DR reprenant les transactions qui ont respectivement ´ecrit ou lu D. On note Dc la derni`ere transaction qui a ´ecrit D et qui a ´et´e clˆotur´ee (Dc ∈ DW ). En outre, chaque transaction simulera ses tentatives d’´ecriture dans un cache WT : Data → Valeurs. Ce cache sera rendu effectif lors de la clˆoture de la transaction. Lors d’une op´eration de lecture/´ecriture d’une donn´ee partag´ee, un conflit survient lorsque la transaction T. . . Action Condition du conflit 1. ´ecrit D ∃i : Ti ∈ DR ∧ Ti > T (•) 2. ´ecrit D ∃i : D ∈ dom(WTi ) ∧ Ti > T 3. lit D ∃i : D ∈ dom(WTi ) ∧ Ti > T L’op´eration d’´ecriture est d´ecrite comme: Proc´edure Write’(D,v) d´ebut Si T ≥ max(DR) ∧ T > Dc Alors WT := WT D → v DW := DW ∪ {T} Sinon avorter T. fin L’op´eration de lecture est d´ecrite comme: Fonction Read’(D)→ v d´ebut Si T > Dc Alors d´ebut Soit T′ = max{t † t ∈ DW ∧ t ≤ T}; Si T′ est clˆotur´ee (i.e., T′ = Dc ) Alors d´ebut DR := DR ∪ {T} retourner WT′ (D) fin Sinon Attendre que T′ clˆoture ou avorte fin Sinon avorter T fin 3 i.e., le d´ebut de la phase de lecture dans la technique pr´ec´edente. 7
  8. 8. Les diagrammes suivants illustrent respectivement divers sc´enarios pouvant se pro- duire lors de la lecture et de l’´ecriture d’une donn´ee. QRZ "' ' ← ' ← ' ← ' ← VL 7 Q H[LVWH SDV DORUV 7 GRLW DWWHQGUH OD ILQ GH 7 VLQRQ 7 SHXW SRXUVXLYUH 77 7 7 7 7 VL 7 H[LVWDLW 7 GHYUDLW DYRUWHU ' ← 7 T5 T2 T4 T3 T1 T6 QRZ ' ← ' ' 77 7 7 7 7 VL 7 RX 7 H[LVWDLHQW 7 GHYUDLW DYRUWHU ' ' T2 T3 T1 T4 T5 Cette technique ´evite les deadlocks, mais a la facheuse tendance d’avorter souvent les transactions. Question 8
  9. 9. • Illustrer par un ou plusieurs diagrammes les cas repris dans les deux algo- rithmes. • Montrer comment cette technique permet de faire de l’interleaving dans la r´ealisation de deux transactions faisant chacune un transfert de compte en banque (Ca → Cb et Cc → Cb). 9

×