Sunteți pe pagina 1din 12

Se va studia problema consistenei bazelor de date pe exemplul unui sistem

de rezervare a locurilor la curse aeriene. Un numr mare de ageni de vnzri vor


accesa relaiile care memoreaz datele de rezervare i vnzare a biletelor de avion.
De exemplu, vor exista relaiile:
CURSE(IdCursa,AeroportPlecare,AeroportSosire,Data,
NrLocuriLibere)
PASAGERI(IdPasager,Nume,Prenume,Adresa, NrCreditCard)
REZERVARI(IdRezervare,IdPasager,IdCursa)
FACTURI(IdFactura,IdPasager,DataFacturarii,Pret)
Cheile primare i strine au fost marcate conform conveniilor care au mai fost
folosite i n seciunile precedente, iar semnificaia atributelor acestor relaii este
destul de clar exprimat chiar prin numele lor. Detalii ca: tipul locului rezervat (turist,
business, etc), reduceri de plat a biletului (bilet copil, etc.), mai multe rezervri
fcute de acelai client, intervalul de timp dintre rezervare i cumprarea biletului,
posibilitatea ca o rezervare s fie anulat, etc., au fost ignorate, dat fiind c nu
modific fondul problemei de consisten a bazei de date.
Atunci cnd un agent de vnzri rezerv un loc la o curs i vinde biletul
corespunztor, se efectueaz mai multe operaii:
1. Se insereaz o linie nou n tabelul PASAGERI, care conine datele
pasagerului.
2. Dac exist locuri libere la cursa dorit, atunci se face propriu-zis
rezervarea, prin inserarea unei linii noi n tabelul REZERVARI, linie care
conine numrul de identificare al pasagerului, numrul de identificare al
cursei i (eventual) numrul locului rezervat; altfel, rezervarea este
imposibil.
3. La achitarea biletului se insereaz o linie n tabelul FACTURI. Acest
nregistrare este folosit pentru a tipri o factur, care va fi folosit pentru
plata n numerar sau va fi trimis companiei de cri de credit.
4. Se emite (tiprete) biletul (pornind de la datele din rezervare i factura
corespunztoare).

Dac sistemul se defecteaz dup ce s-a executat pasul 2, s-a fcut o
rezervare, dar biletul nu a fost facturat i nici emis. Mai ru, dac defeciunea are loc
dup ce s-a executat pasul 3, atunci clientului i se trimite factura, dar el nu a primit
biletul. Astfel de situaii sunt, bineneles, inacceptabile.
Chiar dac nu se defecteaz sistemul, pot s apar probleme dac baza de
date este accesat concurent de mai muli utilizatori. De exemplu, dac doi ageni de
vnzri atribuie acelai loc la doi pasageri diferii, atunci vor fi probleme la
mbarcarea pasagerilor.
Dac toate aciunile aferente unei rezervri ar fi grupate ca o operaie
indivizibil (atomic), o parte din problemele artate mai sus ar disprea.





Temporar

[6]
Blocare

Idea pe care se bazeaz tehnica blocrii este foarte simpl: o tranzacie care a nceput s
opereze asupra unor date trebuie s interzic accesul altor tranzacii la datele respective pn
n momentul n care operaia se ncheie. n acest timp, datele sunt "inute sub cheie" (to lock -
a ncuia, a zvor). Controlul blocrii datelor este asigurt de o component a SGBD-ului
numit Lock Manager (LM). n momentul n care o tranzacie T dorete s acceseze un
anumit obiect al bazei de date va cere componentei LM blocarea obiectului. Dac obiectul
este blocat de o alt tranzacie, tranzacia T va fi pus n stare de ateptare (wait) pn cnd
obiectul este eliberat.

Se poate observa cu uurin c aceast modalitate de blocare este prea restrictiv.
Anomaliile apar doar n cazul actualizrilor datelor, ceea ce sugereaz c o rafinare a tehnicii
implic folosirea a dou tipuri de blocri:

Blocare partajat (share lock sau S lock) - Permite citirea obiectului dar interzice
modificarea acestuia, motiv pentru care mai este numit "blocare pentru citire" (read lock).
Mai multe tranzacii pot bloca simultan pentru citire un anumit obiect.
Blocare exclusiv (exclusive lock sau X lock) - Interzice accesul altor tranzacii la
obiectul blocat, fie pentru citire, fie pentru modificare. Blocarea exclusiv este mai "tare"
dect blocarea partajat, fiind folosit doar pentru actualizri, motiv pentru care mai este
numit "blocare pentru scriere" (write lock).

O situaie special este cea n care o tranzacie blocheaz pentru citire un obiect i
dorete s obin o blocare exclusiv. Dac obiectul respectiv nu este blocat partajat i de
ctre alte tranzacii, blocarea exclusiv este obinut de tranzacia n cauz. Procedeul de
numete "promovarea blocrii" (lock promotion).

n cazul celor mai multe SGBD-uri, blocarea este implicit: orice operaie asupra datelor
este automat precedat de cererea pentru obinerea blocrii datelor respective (S lock pentru
citire, X lock pentru actualizare - ntelegnd prin "actualizare" operaiile UPDATE, INSERT
i DELETE). ncheierea tranzaciei (cu sau fr succes) elibereaz n mod automat blocrile
pe care aceasta le deinea. Anumite sisteme (de pild Adabas D) permit "nlnuirea
tranzaciilor" (transaction chaining) cu pstrarea anumitor blocri (prin clauza KEEP LOCK a
instruciunii COMMIT).

Standardul SQL nu face nici o prezumie legat de modul de implementare a
mecanismelor de control al accesului concurent (prin blocare, prin mrci de timp sau alte
metode) i, n consecin, nu prevede instruciuni explicite de blocare. Cu toate acestea,
majoritatea SGBD-urilor relaionale ofer n propriile dialecte SQL instruciuni de blocare
explicit (LOCK). Anumite sisteme non-relaionale (Raima, de exemplu) folosesc doar
blocri explicite. De obicei, aceste sisteme prevd i instruciuni de deblocare explicit
(UNLOCK).

Dei sunt cele mai uzuale, blocrile partajate i exclusive nu sunt singurele posibile.
Unele SGBD-uri (IBM DB2, Sybase SQL Server, Raima db_VISTA) folosesc o aa-numit
"blocare pentru actualizare" (update lock), care este un nivel intermediar ntre blocarea
partajat i cea exclusiv. Dac mai multe tranzacii blocheaz partajat (pentru citire) un
anumit obiect, una dntre ele (doar una) poate obine o blocare pentru actualizare (remarcai
c o blocare exclusiv nu poate fi obinut n aceste condiii). De obicei utilizarea blocrii
pentru actualizare este posibil doar n situaia unui mecanism de control special (bazat n
general pe versiuni multiple ale datelor) care s avertizeze o alt tranzacie care solicit o
blocare pentru actualizare c datele au fost modificate.

Deadlock

Problema "actualizrii pierdute", folosind blocrile partajate i exclusive ar putea fi
explicat n felul urmator: la momentul t1 tranzacia R1 solicit o blocare partajat a liniei Z
i (presupunnd c linia nu era blocat pentru scriere de o alt tranzacie) o obine. La
momentul t2, tranzacia R2 solicit i ea o blocare partajat a liniei Z i o obine la rndul ei.
Ambele tranzacii blocheaz n acest moment pentru citire linia Z. La momentul t3, tranzacia
R1 solicit blocarea exclusiv a liniei Z, pentru a face o actualizare. Nu obine blocarea,
deoarece linia este blocat pentru citire de tranzacia R2, deci este pus n stare de ateptare.
Tranzacia R2 cere i ea blocarea exclusiv i, evident, nu o obine din motive similare.
Niciuna dntre tranzacii nu poate coninua, deoarece fiecare ateapt ca cealalt s elibereze
linia Z.
Aceast situatie se numeste deadlock sau "interblocare". Este uor de verificat c i n
situaia "analizei inconsistente" se va ajunge la o interblocare. Rezultatul este c se rezolv
problema anomaliilor (ntr-adevr, acestea nu mai apar) dar se obine o alt problem, cea a
deadlock-urilor. Rezolvarea noii probleme cuprinde dou aspecte:

Prevenirea deadlock-ului. Implic stabilirea unui protocol de acces la date care
s fac imposibil apariia situaiilor de deadlock. O variant posibil este ca
fiecare tranzacie s blocheze "n bloc" toate liniile de care are nevoie. Alta
variant este stabilirea unei ordini a obiectelor iar cererile de blocare s fie
rezolvate n conformitate cu aceast ordine. Ambele metode au dezavantajul c
limiteaz semnificativ performanele prin blocarea resurselor pe durate mai lungi
dect cele strict necesare. Pe de alt parte, prima metod nu este aplicabil
ntotdeauna, deoarece este posibil ca o tranzacie s nu cunoasc de la nceput
toate datele de care are nevoie.

Detectarea deadlock-ului. Cea mai simpl metod de detectare a unei situaii de
deadlock este cea bazat pe un mecanism de time-out: dac durata execuei unei
tranzacii depete o valoare prestabilit, sistemul deduce c a aprut un
deadlock. O alt metod se bazeaz pe construirea i meninerea dinamic a unui
"graf de ateptare" (Wait-For Graph). Nodurile acestui graf reprezint tranzaciile
care se execut (T1, T2, ..., Tn) iar arcele reprezint relaia de dependen
(ateptare): existena unui arc de la Ti la Tj semnific faptul c tranzacia Ti
ateapt ca tranzacia Tj s elibereze anumite resurse. Detectarea unui deadlock
revine la detectarea existenei unui ciclu n graful de ateptare.

n practic, cel mai adesea se utilizeaz o mixtur de tehnici: se impune un protocol de
acces care s reduc posibilitatea deadlock-ului(fr s o previn total, dar i fr s inhibeze
semnificativ concuren), se implementeaz un mecanism care s detecteze deadlockurile
cele mai uzuale, lsndu-le pe celelalte pe seama unui mecanism de time-out.

Rezolvarea efectiv a unui deadlock revine la stabilirea unei "victime" dintre tranzaciile
implicate n deadlock i anularea ei (ROLLBACK). Dup ce deadlock-ul a fost nlturat,
tranzacia poate fi lansat din nou n execuie.

Observaii:
a. Desigur, ntr-un deadlock pot s intervin mai mult de dou tranzacii n acest caz este
posibil ca mai multe tranzacii s trebuiasc anulate pentru a debloca execua.
b. Cele mai multe sisteme reprogrameaz automat pentru execue tranzaciile anulate.
Exist ns i sisteme care returneaz doar un cod de eroare aplicaiei, acesteia revenindu-i
sarcina s se ocupe de rezolvarea problemei.

Serializare

Problema care se pune este: cum se poate ti dac execua concurent a unui grup de
tranzacii este corect sau nu?

Definiie: Se numete planificare (schedule) oricare ordine posibil de executre a
operaiilor grupului de tranzacii considerat.

O prim constatare este c, dac se presupune c fiecare tranzacie n parte din grup este
corect, atunci orice planificare serial a tranzaciilor (una dup alta, indiferent de ordine)
este corect. Dei afirmaia este intuitiv, se poate justifica uor prin faptul c orice program
execut o secven de tranzacii (deci niciodat dou tranzacii simultan). Aadar, tranzaciile
din grupul considerat sunt executte de programe diferite (sunt deci independente), ordinea
execuei lor fiind irelevant (de regul FIFO: first in, first out).

n cazul n care se execut operaii ale unei tranzacii n timp ce execua altor tranzacii
nu a fost nc ncheiat avem de-a face cu o planificare intercalat (interleaved), caz n care
este posibil ca execuia s nu fie corect (cum a fost cazul celor trei exemple prezentate la
nceput).Dou planificri ale unui grup de tranzacii sunt echivalente dac vor produce mereu
acelai rezultat, oricare ar fi starea iniial a bazei de date (aceasta nseamn, de fapt, c
operaiile conflictuale sunt n aceeasi ordine).

O planificare este serializabil dac este echivalent cu o planificare serial. Orice
planificare serial fiind corect, nseamn c acesta este criteriul de corectitudine cutat.
Execua unui grup de tranzacii este corect dac s-a fcut conform unei planificri
serializabile.O caracterizare mai puin riguroas, dar mult mai intuitiv a caracterului
serializabil este urmtoarea: Oricare ar fi dou tranzacii A i B dintr-o planificare a unui
grup de tranzacii concurente, fie A precede logic pe B, fie B precede logic pe A. Faptul c
"A precede logic pe B" nseamn c B poate vedea rezultatele execuei tranzaciei A. Deci,
dac considerm toate obiectele vzute de tranzacia A, atunci B vede toate aceste obiecte fie
modificate deja de A, fie n forma n care erau nainte ca modificrile s se produc, dar
niciodat ca un amestec de obiecte modificate i obiecte nemodificate.

Teoria este, desigur, mult mai bogat i specific mai multi algoritmi de verificare a
criteriului enunat. Rezultatul cel mai important din perspectiv practic a acestei teorii este
aa-numita "teorem a seriabilittii" (sau "a blocrii n dou faze"): Dac toate tranzaciile
unui grup de tranzacii concurente sunt bine formate i respect protocolul de blocare n dou
faze, atunci orice planificare legal este serializabil.
Demonstraia nu este dificil (o variant se bazeaz pe graful de precedent al planificrii
i se desfsoar prin reducere la absurd). Importante sunt ns condiiile:
O tranzacie este "bine format" dac orice operaie a tranzaciei este acoperit de o
blocare i toate blocrile sunt eliberate. O operaie (citire sau scriere) este "acoperit de o
blocare" dac tranzacia deine o blocare suficient de puternic a obiectului asupra cruia se
desfsoar operaia.
O planificare este "legal" dac nu se desfsoar n condiiile unor blocri conflictuale.

Un "protocol de blocare" const dintr-un set de restricii impuse ordinii n care
tranzaciile concurente blocheaz i deblocheaz obiectele bazei de date. Protocolul de
blocare n dou faze (two-phase locking) impune urmtoarele dou restricii:

1. nainte de a opera asupra oricrui obiect al bazei de date, o tranzacie trebuie s obin
blocarea respectivului obiect.

2. Dup ce a eliberat o blocare, o tranzacie nu va mai ncerca niciodat s obtin noi
blocri.

Se observ cu usurin explicaia denumirii "n dou faze" (care n-are nimic n comun cu
comiterea n dou faze): conform acestui protocol orice tranzacie trece mai nti printr-o faz
de obinere a blocrilor, dup care trece ntr-o faz de eliberare a blocrilor.

Sarcina asigurrii respectrii acestui protocol revine Lock Manager-ului (desigur, dac
sistemul lucreaz pe baza acestui protocol). Mai observm c protocolul prevede "eliberarea
blocrilor". O regul de "bun sim" spune c un obiect trebuie blocat ct mai puin timp cu
putin, pentru a permite i accesul altor tranzacii la acesta. Din pcate, implementarea
acestui protocol n forma sa cea mai eficient din acest punct de vedere este extrem de
dificil: LM trebuie s "tie" cnd o tranzacie a obinut toate blocrile i nu va mai avea
nevoie de altele (pentru a identifica faza n care se afl); LM trebuie s tie dac tranzacia va
mai avea nevoie de un obiect asupra cruia a efectuat o operaie, deci dac poate sau nu s-l
elibereze (din acelai motiv al identificrii fazelor); n fine, apare problema extrem de dificil
a "anulrii n cascad" a tranzaciilor: n cazul n care o tranzacie a fost anulat n faza a
doua, este posibil ca unele date eliberate de aceasta au fost apoi blocate de alte tranzacii, caz
n care aceste tranzacii trebuie la rndul lor anulate. Din cauza acestor dificulti, majoritatea
sistemelor implementeaz o variant mai restrictiv a protocolului, n care toate eliberrile
blocrilor unei tranzacii sunt amnate pn la terminarea tranzaciei (fie prin COMMIT fie
prin ROLLBACK).

Este deci rezonabil s se considere c blocrile obinute de o tranzacie sunt pstrate pn
la terminarea acesteia, cu toate c n felul acesta intervalul de timp n care un obiect este
blocat este de regul mai lung dect minimul necesar. Compromisul este i aici prezent:
simplificarea mecanismelor implementate n Lock Manager compenseaz scderea nivelului
de concuren prin blocri de mai lung durat. Exist ns situaii n care se poate admite un
grad oarecare de interferen, caz n care nivelul concurentei poate fi crescut prin "relaxarea"
protocolului de blocare (n spet prin admiterea unor condiii n care anumite blocri pot fi
eliberate naintea terminrii tranzaciei)

Blocarea ierarhic

Tehnica blocrii ierarhice se refer la sistemele care admit mai multe granulaii ale
blocrii i a fost introdus de Jim Gray i colaboratorii si nc din 1975.

Ideea de la care se pleac este c pentru o obine o blocare la nivel de articol (linie de
tabel), o tranzacie trebuie s-i manifeste aceast intenie, cernd mai nti o blocare la nivel
de tabel. n felul acesta se simplific procesul de detectare a unor cereri conflictuale de
blocare la nivel de linie, deoarece ele trebuie nti s se manifeste la nivel de tabel.
Protocolul bazat pe "intenii de blocare" (intent locking) introduce trei noi tipuri de blocare
(la nivel de tabel), alturi de cele dou tipuri de blocri uzuale (S-lock i X-lock) care, aa
cum am artat deja, au sens i la nivel de tabel. Avem astfel cinci tipuri de blocri pe care o
tranzacie T le poate solicita la nivelul ntregii tabele R, prezentate n ordinea cresctoare a
"triei" lor relative:

IS - intent shared : Tranzacia T intenioneaz s blocheze pentru citire (S lock) anumite
linii ale tabelei R, pentru a garanta stabilitatea acestora n timpul procesrilor pe care le va
efectua.

IX - intent exclusive : La fel ca IS, dar T s-ar putea s vrea s modifice anumite articole
i deci s solicite blocarea exclusiv a acestora.

S shared : Este obinuita blocare partajat. T admite citiri concurente ale tabelei R, dar
nu i scrieri. T nu va face nici o scriere la nivelul liniilor tabelei.

SIX - shared intent exclusive : Combin S i IX. n plus fa de S, T s-ar putea s vrea
s modifice anumite linii din R i, n consecin, s solicite blocarea exclusiv a acestora.

X exclusive : T nu admite citiri concurente n tabela R. T ar putea s actualizeze
anumite linii ale tabelei R.

Cteva observatii:

a. Noiunea de "trie" a blocrii se refer la faptul c o cerere de blocare de un anumit tip
care eueaz, va eua cu siguran pentru orice tip mai "tare".

b. Tipurile IX i S sunt egale din punct de vedere al "triei".

c. i aceste tipuri de blocri sunt n mod obinuit cerute n mod implicit. Cu toate
acestea, sistemele care implementeaz aceste tipuri de blocare (DB2, OpenIngres) ofer de
obicei i o instruciune de blocare explicit pentru aceste tipuri.

d. Varianta pe care am prezentat-o este mult simplificat. De fapt blocrile se pot referi
la orice granulaii i orice obiecte ale bazei de date (inclusiv indeci).

n fine, protocolul bazat pe intenii de blocare (intent locking protocol), impune dou
reguli care mbin blocrile la nivel de tabel i de articol ntr-o combinaie care adesea s-a
dovedit mai eficient n aplicatii:

1. nainte de a obine o blocare partajat (S) la nivel de linie, o tranzacie trebuie s
obin o blocare de tip IS (sau mai tare) la nivelul ntregii tabele.

2. nainte de a obine o blocare de tip exclusiv (X) la nivel de linie, o tranzacie trebuie s
obtin o blocare de tip IX sau mai tare la nivelul ntregii tabele.




Ce nseamn s blocm : Cnd o tranzacie blocheaz partajat (part_bloc) o anumit
unitate de memorie, o alt tranzacie nu mai poate s rescrie tot acolo, iar cnd o tranzacie
blocheaz exclusiv (ex_bloc) o alta nu mai poate nici s o citeasc.
Despre ce unitate de memorie este vorba? Aceasta este problema granularitii la
care se face blocajul. Blocajul se poate face la nivel de:
ntreaga baz de date
tabela(fiier)
nregistrare (cel mai des)
cmp din nregistrare
Mai spunem c avem granularitate dinamic atunci cnd SGBD-ul poate s schimbe
granularitatea n timpul unei tranzacii.
Cititorul poate s demonstreze singur pe un exemplu (vezi problema ) c numai simpla
blocare urmat cndva de deblocare (debloc) nu asigur serializabilitatea.
Serializabilitatea este asigurat dac se respect protocolul de blocare n dou faze.
Acesta const din mprirea tranzaciei n dou faze una de blocri i creteri de blocaje i a
doua de descreteri i deblocaje. Aceasta nseamn c dup ce s-a fcut prima deblocare nu se
mai pot face blocri.
Urmtoarele trei exemple reiau tranzaciile T
1
,T
2
respectiv T
3
, T
4
, T
5
, T
6
cu protocolul n
dou faze i realizeaz planuri serializabile.



Time

T
1
T
2
bal
x
A

t
1
begin_transaction 100
A

t
2
begin_transaction ex_bloc(bal
x
) 100
A

t
3
ex_bloc(bal
x
) cit(bal
x
) 100
A

t
4
ATEAPT bal
x
= bal
x
+100 100
A

t
5
ATEAPT scrie(bal
x
) 200
A

t
6
ATEAPT debloc(bal
x
) 200
A

t
7
cit(bal
x
) commit 200
A

t
8
bal
x
= bal
x
-10 200
A

t
9
scrie(bal
x
) 190
A

t
10
debloc(bal
x
) 190
A

t
11
commit 190


Time

T
3
T
4
bal
x
A

t
1
begin_transaction 100
A

t
2
ex_bloc(bal
x
) 100
A

t
3
cit(bal
x
) 100
A

t
4
begin_transaction bal
x
= bal
x
+100 100
A

t
5
ex_bloc(bal
x
) scrie(bal
x
) 200
A

t
6
ATEAPT debloc(bal
x
) 100
A

t
7
ATEAPT rollback 100
A

t
8
cit(bal
x
) 100
A

t
9
bal
x
= bal
x
-10 100
A

t
10
scrie(bal
x
) 90
A

t
11
debloc(bal
x
) 90
A

t
12
commit 90





Time

T
5
T
6
bal
x
bal
y
bal
z
sum
A

t
1
begin_transaction 100 50 25
A

t
2
begin_transaction sum = 0 100 50 25 0
A

t
3

ex_bloc(bal
x
)
100 50 25 0
A

t
4
cit(bal
x
) part_bloc(bal
x
) 100 50 25 0
A

t
5
bal
x
= bal
x
-
10
ATEAPT 100 50 25 0
A

t
6
scrie(bal
x
) ATEAPT 90 50 25 0
A

t
7

ex_bloc(bal
z
)
ATEAPT 90 50 25 0
A

t
8
cit(bal
z
) ATEAPT 90 50 25 0
A

t
9
bal
z
= bal
z
+
10
ATEAPT 90 50 25 0
A

t
10
scrie(bal
z
) ATEAPT 90 50 35 0
A

t
11
debloc(bal
x

, bal
z
)
ATEAPT 90 50 35 0
A

t
12
commit ATEAPT 90 50 35 0
A

t
13
cit(bal
x
) 90 50 35 0
A

t
14
sum = sum + bal
x
90 50 35 90
A

t
15
part_bloc(bal
y
) 90 50 35 90
A

t
16
cit(bal
y
) 90 50 35 90
A

t
17
sum = sum + bal
y
90 50 35 140
A

t
18
part_bloc(bal
z
) 90 50 35 140
A

t
19
cit(bal
z
) 90 50 35 140
A

t
20
sum = sum + bal
z
90 50 35 175
A

t
21

debloc(bal
x
,bal
y
,bal
z
)
90 50 35 175
A

t
22
commit 90 50 35 175



Protocolul de blocare n dou faze asigur serializanilitatea dar nu ne scutete de
probleme. Pezentm n cele dou exemple urmtoare rollback-ul n cascad i blocajul
ciclic.
La momentul t14 tranzacia T
7
face rollback (dintr-un motiv extern) i, pentru c T
8

este dependent de T
7
care a citit o nregistrare care a fost actualizat de T
7
, trebuie s
fac i T
8
rollback, ceea ce pe urm se ntmpl i cu T
9
.






Time

T
7
T
8
T
9
A

t
1
begin_transaction
A

t
2
ex_bloc(bal
x
)
A

t
3
cit(bal
x
)
A

t
4
part_bloc(bal
y
)
A

t
5
bal
x
= bal
y
+
bal
x


A

t
6
scrie(bal
x
)
A

t
7
debloc(bal
x
) begin_transaction
A

t
8
ex_bloc(bal
x
)
A

t
9
cit(bal
x
)
A

t
10
bal
x
= bal
x
+100
A

t
11
scrie(bal
x
)
A

t
12
debloc(bal
x
)
A

t
13

A

t
14
rollback
A

t
15
rollback begin_transaction
A

t
16

part_bloc(bal
x
)
A

t
17

A

t
18
rollback





O alt problem este blocarea ciclic prezentat n exemplul urmtor. Cele dou trnzacii
T
10
i T
11
se blocheaz reciproc.





Time

T
10
T
11

A

t
1
begin_transaction
A

t
2
ex_bloc(bal
x
) begin_transaction
A

t
3
cit(bal
x
) ex_bloc(bal
y
)
A

t
4
bal
x
= bal
x
-10 cit(bal
y
)
A

t
5
scrie(bal
x
) bal
y
= bal
y
+100
A

t
6
ex_bloc(bal
y
) scrie(bal
y
)
A

t
7
ATEAPT ex_bloc(bal
x
)
A

t
8
ATEAPT ATEAPT
A

t
9
ATEAPT ATEAPT
A

t
10
ATEAPT
A

t
11



Blocajul ciclic este detectat , de obicei, prin constuirea unui graf de preceden care arat
dependena ntre tranzacii n felul urmtor:
- se creaz un nod pentru fiecare tranzacie
- se creaz o muchie direcionat Ti Tj dac tranzacia Ti ateapt s
blocheze o nregistrare care este deja blocat de Tj.
Pe acest graf se detecteaz un blocaj ciclic dac exist un circuit. Graful tranzactiilor:







O alt metod de a evita blocajul ciclic pstrnd serializabilitatea este protocolul cu
marcarea timpului (time stamp). Acest protocol ataeaz un timp (timpul real din calculator
sau un numr care se mrete autmat de cte ori este solicitat) fiecrei tranzacii (marc(T)) i
timpul tranzaciei care realizeaz operaia fiecrei citiri sau scrieri a unei nregistrri. Deci
fiecare tranzacie va avea o valoare de marcj i fiecare nregiistrare prelucrat va avea dou
marcaje; unul care spune ce marcaj a avut tranzacia care a citit-o (cit_marc) i cellalt care
spune ce marcaj a avut tranzacia care a scris-o (scri_marc).
Numai n urmtoarele trei situaii se pun probleme deosebite:
1. Tranzacia T cere s citeasc o nregistrare x care a fost deja actualizat de o
tranzacie cu scri_marc(x) > marc(T), adic o nregistrare scris de o tranzacie care a
nceput mai trziu. Ce ar rescrie ea ar putea da natere la inconsisten deci trnzacia
respectiv trebuie ntrerupt.
2. Tranzacia cere s scrie nregistrarea x a crei valoare a fost deja citit de o tranzacie
care a nceput mai trziu marc(T) < cit_marc(x). Aceasta nseamn c tranzacia vrea
s rescrie o nregistrare, pe care o alt tranzacie nceput mai trziu, a citit-o i o
folosete. i n acest caz tranzacia trebuie ntrerupt.
3. Tranzacia cere s scrie o nregistrare x a crei valoare a fost deja scris de o
tranzacie care a nceput mai trziu, adic marc(T) < scri_marc(x). Este o ncercare de
a scrie o valoare perimat i n acest caz se ignor aceast scriere.
n figura urmtoare se poate observa cum funcioneaz acest protocol.

T
10
T
11

Time

Op T
7
T
8
T
9
A

t
1
begin_transaction
A

t
2
cit(bal
x
) cit(bal
x
)
A

t
3
bal
x
= bal
x
+10 bal
x
= bal
x
+100
A

t
4
scrie(bal
x
) scrie(bal
x
) begin_transaction
A

t
5
cit(bal
y
) cit(bal
y
)
A

t
6
bal
y
= bal
y
+20 bal
y
= bal
y
+20 begin_transaction
A

t
7
cit(bal
y
) cit(bal
y
)
A

t
8
scrie(bal
y
) scrie(bal
y
)
**

A

t
9
bal
y
= bal
y
+30 bal
y
= bal
y
+30
A

t
10
scrie(bal
y
) scrie(bal
y
)
A

t
11
bal
z
=100 bal
z
=100
A

t
12
scrie(bal
z
) scrie(bal
z
)
A

t
13
bal
z
=50 bal
z
=50 commit
A

t
14
scrie(bal
z
) scrie(bal
z
)
*
begin_transaction
A

t
15
cit(bal
y
) commit cit(bal
y
)
A

t
16
bal
y
= bal
y
+20 bal
y
= bal
y
+20
A

t
17
scrie(bal
y
) scrie(bal
y
)
A

t
18
commit




* la timpul t
8
scrierea de ctre tranzacia T
13
violeaz regula 2 i de aceea este ntrerupt
i reluat la momentul t
14

** la timpul t
14
scrierea de ctre tranzacia T
12
poate fi ignorat conform celei de a treia
reguli