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