Mecanisme de control al concurentei in sistemele de baze de date distribuite

1. Mecanisme de control al concurentei in sistemele de baze de date distribuite Valentin Drîmboceanu Facultatea de Electronică, Telecomunicaţii şi Tehnologia Informaţiei Bucureşti, 2008

2. Cuprins 1. Tranzactii. Executii concurente. Serializabilitate. Recuperabilitate 1.1 Tranzactii 1.2 Executii concurente 1.3 Serializabilitate 1.4 Recuperabilitate 2. Protocoale de control al concurentei 2.1 Protocoale bazate pe blocare 2.2 Protocoale bazate pe stampila de timp 2.3 Protocoale bazate pe validare 2.4 Granularitate multipla 2.5 Scheme multiversiune 2.6 Send on demand

3. Tranzactii Doua tipuri de integritate : • Integritatea de baza-preocupata de problemele avariei software sau hardware sau de problemele distribuirii unei resurse mai multor utilizatori. • Integritatea semantica-obiectivul sau global este de asigura ca o anumita baza de date este oglindirea corecta a lumii reale pe care incearca sa o reprezinte. Managementul tranzactiei -unul dintre cele mai importante aspecte ale integritatii de baza -implica asigurarea accesului concurent la o baza de date si asigurarea consistentei acestei baze de date intr-un mediu multi-user Tranzactie- procedura care cauzeaza schimbari unei baze de date sau obtine date dintr-o baza de date -”o unitate logica de lucru “(Elmasri & Navathe, 2000) -corespunde unei activitati coerente indeplinite de un grup, o organizatie sau un proces software dintr-o baza de date

4. Tranzactii ACID – conditii ce trebuie indeplinite de orice tranzactie: •Atomicitate -sistemul bazei de date ar trebui sa sigure fie ca toate actiunile unei tranzactii sunt realizate, fie niciuna. •Consistenta – o tranzactie ar trebui sa conserve consistenta si integritatea bazei de date •Izolare -managerul tranzactiei trebuie sa ofere iluzia ca tranzactia ruleaza izolat fata de alte tranzactii •Durabilitate -cand o trazanctie se incheie, schimbarile facute de ea ar trebui sa fie durabile, sa se conserve in cazul unor avarii hardware sau software

5. Executii concurente Motive pentru executia concurenta a tranzactiilor: •O mai buna utilizare a benzii si a resurselor - paralelismul CPU si a sistemului I/O poate fi exploatat pentru a rula multiple tranzactii in paralel. Procesorul si discul stau mai putin timp in starea idle. • Timp de asteptare redus -executia concurenta reduce intarzierile neprevazute in rularea tranzactiilor Sistemul bazei de date trebuie sa controleze interactiunea dintre tranzactiile concurente pentru a preveni distrugerea de catre acestea a consistentei bazei de date.

6. Executii concurente Exemplu : Fie T1 si T2 doua tranzactii care transfera fonduri dintr-un cont intr-altul. Tranzactia T1 transfera $50 din contul A in contul B. T1: citeste(A); A := A − 50; scrie(A); citeste(B); B := B + 50; scrie(B). Tranzactia T2 transfera 10 procente din contul A in contul B. T2: citeste(A); temp := A * 0.1; A := A − temp; scrie(A); citeste(B); B := B + temp; scrie(B).

7. Executii concurente Presupunem ca valorile curente ale conturilor A si B sunt $1000 si respectiv $2000. T1 T2 T1 T2 Planificatoare seriale A = $ 855 , B = $ 1245 A = $ 850 , B = $ 1250 Secventele de executie descrise sunt denumite planificatoare. Ele reprezinta in ordine cronologica instructiunile care sunt executate in sistem. Un planificator pentru un set de tranzactii trebuie sa fie constituit din toate instructiunile acelor tranzactii, si trebuie sa conserve ordinea in care instructiunile apar in fiecare tranzactie individuala.

8. Executii concurente T1 T2 T1 T2 Planificatoare concurente A = $ 855 , B = $ 1245 A = $ 950 , B = $ 2100 Componenta de control al concurentei are sarcina de a se asigura ca orice planificator care se executa va lasa baza de date intr-o stare consistenta.

9. 3 anomalii asociate cu executiile intercalate Doua actiuni asupra aceluiasi articol de date intra in conflict daca cel putin una dintre ele este o operatie de scriere. Cele 3 anomalii pot fi descrise in functie de momentul in care actiunile celor doua tranzactii T1 si T2 intra in conflict: intr-un conflict scriere-citire (write-read-WR) T2 citeste un articol de date scris anterior de catre T1; similar se definesc si conflictele de citire – scriere (read-write -RW) si de scriere-scriere ( write-write -WW).

10. Citirea datelor necomise (Reading Uncommitted Data –conflicte WR ) O tranzactie T2 ar putea sa citeasca un obiect din baza de date A care a fost modificat de catre o alta tranzactie T1, care nu a comis inca (dirty read). Fie doua tranzactii T1 si T2, care rulate separat, conserva consistenta bazei de date: T1 transfera $100 din A in B, iar T2 incrementeaza atat pe A cat si pe B cu 6 procente (sa presupunem ca dobanda anuala este stocata in aceste doua conturi). Presupunand ca actiunile lor sunt intercalate astfel incat (1) programul de transfer extrage $100 din contul A (2) programul T2 citeste valorile curente ale conturilor A si B si adauga 6 procente la fiecare (3) programul de transfer crediteaza cu $100 contul B.

11. Citiri nerepetabile ( Unrepeatable Reads –conflicte RW) O tranzactie T2 ar putea schimba valoarea unui obiect A care a fost citit de o tranzactie T1, timp in care T1 este inca in desfasurare. Aceasta situatie produce doua probleme: • Daca T1 incearca sa citeasca iar valoarea lui A, va obtine un rezultat diferit, desi nu l-a modificat pe A in acest timp • Presupunem ca atat T1 cat si T2 citesc aceeasi valoare a lui A, sa spunem 5, si apoi T1, care vrea sa incrementeze A cu 1, il schimba in 6, iar T2, care vrea sa decrementeze A cu 1, decrementeaza valoarea pe care o citeste (adica 5) si schimba pe A in 4. Rularea acestor tranzactii intr-o ordine seriala ar trebui sa-l lase pe A avand valoarea finala 5; deci, executia intercalata conduce la o stare inconsistenta

12. Suprascrierea datelor necomise (Overwriting Uncommitted Data –conflicte WW) O tranzactie T2 ar putea suprascrie valoare unui obiect A, care a fost deja modificata de o tranzactie T1, in timp ce T1 este inca in desfasurare. Presupunem ca Harry si Larry sunt doi angajati, si ca salariile lor trebuie sa fie mentinute egale. Tranzactia T1 seteaza salariile lor la $1,000, iar tranzactia T2 seteaza salariile lor la $2,000. T1 seteaza salariul lui Harry la $1,000, T2 seteza salariul lui Larry la $2,000, T1 seteza salariul lui Larry la $1,000, si in sfarsit T2 seteaza salariul lui Harry la $2,000.

13. Serializabilitate Un planificator serializabil peste un set S de tranzactii comise este un planificator al carui efect asupra unei instante consistente a bazei de date este garantat a fi acelasi cu efectul unui planificator complet serial peste setul S. Adica, instanta bazei de date care rezulta in urma acestui planificator este identica cu instanta bazei de date care rezulta in urma executarii tranzactiilor intr-o ordine seriala. Conflict serializabilitatea Doua planificatoare sunt conflict echivalente daca ele invoca actiunile (acelasi set de actiuni) acelorasi tranzactii si ele ordoneaza fiecare pereche de actiuni conflictuale a doua tranzactii, in acelasi mod. Un planificator este conflict serializabil daca este conflict echivalent cu un planificator serial.

14. Serializabilitae Serializabilitate esentiala Doua planificatoare S1 si S2 peste acelasi set de tranzactii-orice tranzactie care apare fie in S1 fie in S2 trebuie sa apara deasemenea in celalalt - sunt esential echivalente in urmatoarele conditii: 1. Daca Ti citeste valoarea initiala a obiectului A in S1, trebuie sa citeasca deasemenea si valoarea initiala a lui A in S2. 2. Daca Ti citeste o valoare a lui A scrisa de catre Tj in S1, trebuie sa citeasca si valoarea lui A scrisa de Tj in S2. 3. Pentru fiecare articol de date A, tranzactia (daca exista una) care realizeaza scrierea finala a lui A in S1 trebuie sa realizeze si scrierea finala a lui A in S2. Un planificator este esential serializabil daca este esential echivalent cu un planificator serial. Orice planificator conflict serializabil este esential serializabil, desi reciproca nu este adevarata.

15. Recuperabilitate Un planificator recuperabil este unul in care, pentru fiecare pereche de tranzactii Ti si Tj in care Tj citeste un articol de date scris anterior de catre Ti, operatia de comitere a lui Ti se produce inainte de operatia de comitere a lui Tj. Exemplu de planificator nerecuperabil-daca actiunea de comitere se produce imediat dupa instructiunea citeste (A) Fenomenul in care esecul unei singure tranzactii conduce la situatia in care o serie de alte tranzactii fac rollback se numeste rollback in cascada. Formal, un planificator fara rollback in cascada este unul in care, pentru fiecare pereche de Ti si Tj in care Tj citeste un articol de date scris anterior de catre Ti, operatia de comitere a lui Ti se produce inainte de operatia de citire a lui Tj . Fiecare planificator fara rollback in cascada este si recuperabil.

16. Protocoale de control al concurentei Protocoale bazate pe blocare In timp ce o tranzactie acceseaza un articol de date, nici o alta tranzactie nu poate modifica acel articol. Cea mai raspandita metoda de a implementa aceasta cerinta este de a permite unei tranzactii sa acceseze un articol de date doar daca are o blocare asupra acelui articol. Moduri de blocare: 1. Partajat. Daca o tranzactie Ti a obtinut o blocare partajata (shared-mode lock) (notata cu S) asupra unui articol Q, atunci Ti poate citi, dar nu poate scrie Q. 2. Exclusiv.Daca o tranzactie Ti a obtinut o blocare exclusiva (exclusive-mode lock) (notata cu X) asupra articolului Q, atunci Ti poate si sa citeasca si sa scrie Q. Presupunem ca o tranzactie Ti solicita o blocare de tip A asupra articolului Q asupra caruia tranzactia Tj detine o blocare de tip B. Daca tranzactia Ti poate obtine o blocare asupra lui Q imediat, in ciuda prezentei blocarii B, atunci spunem ca modul A este compatibil cu modul B. O asemenea functie de compatilitate a blocarilor poate fi reprezentata convenabil printr-o matrice:

17. Protocoale bazate pe blocare O tranzactie solicita o blocare partajata asupra articolului Q prin executarea instructiunii blocheaza-S(Q). Similar, o tranzactie solicita o blocare exclusiva prin instructiunea blocheaza-X(Q). O tranzactie poate debloca un articol Q prin instructiunea deblocheaza(Q). Pentru a accesa un articol de date, tranzactia Ti trebuie mai intai sa blocheze articolul. Fie tranzactia T1 care transfera $50 din contul B in contul A si tranzactia T2 care afiseaza suma totala de bani din conturile A si B—adica suma A + B . T1: blocheaza-X(B); citeste(B); B := B − 50; scrie(B); deblocheaza(B); blocheaza-X(A); citeste(A); A := A + 50; scrie(A); deblocheaza(A). T2: blocheaza-S(A); citeste(A); deblocheaza(A); blocheaza-S(B); citeste(B); deblocheaza(B); afiseaza(A + B).

18. Protocoale bazate pe blocare T1 T2 managerul de control al concurentei

19. Protocoale bazate pe blocare T3: blocheaza-X(B); citeste(B); B := B − 50; scrie(B); blocheaza-X(A); scrie(A); A := A + 50; scrie(A); deblocheaza(B); deblocheaza(A). T4: blocheaza-S(A); citeste(A); blocheaza-S(B); citeste(B); afiseaza(A + B); deblocheaza(A); deblocheaza(B). planificator partial-se ajunge la blocaj

20. Protocoale bazate pe blocare Cand o tranzactie solicita o blocare asupra unui articol de date intr-un anumit mod, si nici o alta tranzactie nu are o blocare asupra aceluiasi articol intr-un mod conflictual, blocarea poate fi acordata. Putem evita starea de “infometare” (starvation) a tranzactiilor prin acodarea blocarilor in urmatoarea maniera : Cand o tranzactie Ti solicita o blocare asupra unui articol de date Q intr-un mod particular M, managerul de control al concurentei acorda blocarea daca 1. Nu exista o alta tranzactie care sa aiba o blocare asupra lui Q intr-un mod care intra in conflict cu M. 2. Nu exista o alta tranzactie care sa astepte o blocare asupra lui Q, si care a facut solicitarea de blocare inaintea lui Ti. Deci o solicitare de blocare nu va fi impiedicata de o solicitare de blocare facuta mai tarziu.

21. Protocoale bazate pe blocare Protocolul bifazic ((2PL-The Two-Phase Locking Protocol) Acest protocol asigura faptul ca orice tranzactie lanseaza cereri de blocare si deblocare in doua faze: 1. Faza crescatoare. O tranzactie poate obtine blocari, dar nu poate ridica nici o blocare. 2. Faza descrescatoare. O tranzactie poate ridica blocari, dar nu poate obtine noi blocari Punctul din planificator unde tranzactia a obtinut blocarea sa finala( sfarsitul fazei crescatoare) este numit punctul de blocare (lock point) al tranzactiei. Tranzactiile pot fi ordonate in functie de punctele lor de blocare- aceasta ordonare este defapt o ordonare a serializabilitatii tranzactiilor. Protocolul bifazic nu asigura absenta blocajelor si nici a rollback-ului in cascada. T5 T6 T7 Planificator partial cu blocare bifazica

22. Protocoale bazate pe blocare • Protocolul bifazic ((2PL-The Two-Phase Locking Protocol) • Protocolul bifazic strict (strict two-phase locking protocol) • o varianta modificata a protocolului bifazic • rollback-ul in cascada este evitat • –solicita, pe langa blocarea bifazica si ca toate blocarile exclusive ale unei tranzactii sa fie mentinute pana tranzactia este comisa. Orice data scrisa de o tranzactie necomisa este blocata intr-un mod exclusiv pana cand tranzactia comite, prevenind citirea datei de catre o alta tranzactie. • Protocolul bifazic riguros (rigorous two-phase locking protocol) • o varianta modificata a protocolului bifazic • cere ca toate blocarile sa fie tinute pana cand tranzactia comite. • tranzactiile pot fi serializate in ordinea in care comit. • Cele mai multe sisteme de baze de date implementeaza fie protocolul bifazic strict fie protocolul bifazic riguros.

23. Protocoale bazate pe blocare Protocolulbifazic T8: citeste(a1); citeste(a2); . . . citeste(an); scrie(a1). T9: citeste(a1); citeste (a2); afiseaza (a1 + a2). Rafinament al bazelor protocolului bifazic- in care conversia blocarilor este permisa (lock conversions) . upgrade -conversia de la modul partajat la exclusiv(doar in faza crescatoare) downgrade -conversia de la modul exclusiv la partajat(doar in faza descrescatoare). Protocolul bifazic cu conversie a blocarilor genereaza doar planificatoare conflict serializabile. Daca blocarile exclusive sunt mentinute pana la sfarsitul tranzactiei, planificatoarele sunt lipsite de rollback in cascada.

24. Protocoale bazate pe blocare Protocoale bazate pe grafuri Daca dorim sa dezvoltam protocoale care nu sunt bifazice, avem nevoie de informatii suplimentare asupra modului in care fiecare tranzactie va accesa baza de date (de exemplu solicita detinerea apriori de informatii legate de ordinea in care articolele de date vor fi accesate). Impunem o ordonare partiala → asupra setului D = {d1, d2, . . ., dh} de articole de date. Daca di → dj , atunci orice tranzactie care acceseaza atat di cat si dj trebuie sa acceseze di inainte sa acceseze dj. D poate fi acum vazut ca un graf aciclic, numit graful bazei de date . Protocolul arborescent (tree protocol) - este restrictionat la a folosi doar blocari exclusive-singura instructiune de blocare permisa este blocheaza-X. Fiecare tranzactie Ti poate bloca un articol de date cel mult o data, si se pot observa urmatoarele reguli: 1. Prima blocare a lui Ti poate fi asupra oricarui articol de date. 2. Ulterior, un articol de date Q poate fi blocat de Ti doar daca parintele lui Q este momentan blocat de Ti. 3. Articolele de date pot fi deblocate oricand. 4. Un articol de date care a fost blocat si deblocat de Ti nu poate fi ulterior blocat iarasi de catre Ti.

25. Protocoale bazate pe blocare Protocolul arborescent Toate planificatoarele care sunt legale in cadrul protocolului arborescent sunt conflict serializabile. Urmatoarele patru tranzactii urmeaza protocolul arborescent. Sunt prezentate doar instructiunile de blocare si deblocare.: T10: blocheaza-X(B); blocheaza-X(E); blocheaza-X(D); deblocheaza(B); deblocheaza(E); blocheaza-X(G); deblocheaza(D); deblocheaza(G). T11: blocheaza -X(D); blocheaza -X(H); deblocheaza (D); deblocheaza (H). T12: blocheaza -X(B); blocheaza -X(E); deblocheaza (E); deblocheaza (B). T13: blocheaza -X(D); blocheaza -X(H); deblocheaza (D); deblocheaza (H). Acest protocol asigura absenta blocajelor. Nu asigura recuperabilitatea si absenta rollback-ului in cascada. Pentru a asigura aceste doua lucruri, protocolul poate fi modificat pentru a nu permite eliberarea blocarilor exclusive pana la finalul tranzactiei-se reduce concurenta.

26. Protocoale bazate pe blocare Protocolul arborescent Avantaje fata de protocolul bifazic: - este lipsit de blocaje, deci nu sunt necesare operatii de rollback. - deblocarea se poate produce mai devreme( timpi de asteptare mai scurti si cresterea concurentei). Dezavantaj- in anumite cazuri, o tranzactie trebuie sa blocheze articolele de date pe care nu le acceseaza

27. Protocoale bazate pe stampila de timp Stampile de timp Fiecarei tranzactii Ti, ii asociem o stampila de timp fixa si unica, TS(Ti). Daca unei tranzactii Ti i s-a asignat o stampila de timp TS(Ti), si o noua tranzactie Tj intra in sistem, atunci TS(Ti) < TS(Tj . Doua metode simple pentru implementarea acestei scheme: 1.Utilizarea valorii ceasului sistemului ca stampila de timp 2.Utilizarea unui contor logic care este incrementat dupa ce o noua stampila de timp a fost asignata; Fiecarui articol de date Q are doua valori pentru stampila de timp: • W-timestamp(Q) - indica cea mai mare stampila de timp dintre stampilele tuturor tranzactiilor care au executat cu succes operatia scrie(Q). • R-timestamp(Q) - indica cea mai mare stampila de timp dintre stampilele tuturor tranzactiilor care au executat cu succes operatia citeste(Q).

28. Protocoale bazate pe stampila de timp Protocolul ordonariistampilelor de timp Protocolul ordonarii stampilelor de timp asigura ca orice operatii de citire sau scriere conflictuale sunt executate in ordinea stampilelor de timp. Acest protocol functioneaza in modul urmator: 1. Ti realizeaza o operatie citeste(Q). a. Daca TS(Ti) < W-timestamp(Q), atunci Ti are nevoie sa citeasca o valoare a lui Q care deja a fost suprascrisa. In acest moment, operatia de citire este respinsa, iar Ti face rollback. b. Daca TS(Ti) ≥ W-timestamp(Q), atunci operatia de citire este executata, si R-timestamp(Q) este setata la valoarea maxima a lui R-timestamp(Q) si TS(Ti). 2. Ti realizeaza o operatie scrie(Q). a. Daca TS(Ti) < R-timestamp(Q), atunci valoarea lui Q pe care Ti o produce a fost necesara anterior, iar sistemul a presupus ca valoarea nu va fi obtinuta nociodata. In acest moment, sistemul respinge operatia de scriere si Ti face rollback. b. Daca TS(Ti) < W-timestamp(Q), atunci Ti incerca sa scrie o valoare veche a lui Q. In acest moment, sistemul respinge aceasta operatie de scriere si Ti face rollback. c. Altfel, sistemul executa operatia de scriere si seteaza W-timestamp(Q) la valoarea TS(Ti).

29. Protocoale bazate pe stampila de timp Protocolul ordonariistampilelor de timp T14: citeste(B); citeste(A); afiseaza(A + B). T15: citeste(B); B := B − 50; scrie(B); citeste(A); A := A + 50; scrie(A); afiseaza(A + B). Asigura conflict serializabilitatea- pentru ca operatiile conflictuale sunt procesate in ordinea stampilelor de timp. Asigura absenta blocajelor, din moment ce nicio tranzactie nu asteapta la nesfarsit. Exista posibilitatea de “infometare” a tranzactiilor lungi daca o secventa de tranzactii conflictuale scurte cauzeaza reinceperea tranzactiei lungi. Protocolul poate genera planificatoare care nu sunt recuperabile.

30. Protocoale bazate pe stampila de timp Regula de scriere a lui Thomas O varianta modificata a protocolului ordonarii stampilelor de timp care pemite un potential al concurentei crescut Regulile pentru operatiile de citire raman neschimbate, regulile pentru operatiile de scriere, sunt intrucatva diferite: Presupunem ca tranzactia Ti face o operatie scrie(Q). 1. Daca TS(Ti) < R-timestamp(Q), Ti face roolback. 2. Daca TS(Ti) < W-timestamp(Q), atunci Ti incearca sa scrie o valoare veche a lui Q. Deci aceasta operatie poate fi ignorata. 3. Altfel, sistemul executa operatia de scriere si seteaza W-timestamp(Q) la valoarea lui TS(Ti). Aici ignoram operatia de scriere veche, cand TS(Ti) < W-timestamp(Q).

31. Protocoale bazate pe validare Presupunem ca fiecare tranzactie Ti se executa in doua sau trei faze diferite: 1. Faza de citire. Se ajunge la valorile diferitelor articole de date si acestea sunt stocate in variabile locale lui Ti. Se realizeaza toate operatiile de scriere asupra unor variabile locale temporare. 2. Faza de validare. Sistemul determina daca poate copia in baza de date variabilele locale temporare, fara a provoca o violare a serializabilitatii. 3. Faza de scriere. Daca tranzactia Ti trece cu succes de faza de validare (pasul 2), atunci sistemul introduce actulizarile in baza de date. Altfel, sistemul face rollback lui Ti. Asociem trei stampile de timp diferite tranzactiei Ti: 1. Start(Ti), momentul in care Ti isi incepe executia. 2. Validare(Ti), momentul in care Ti si-a terminat faza de citire si isi incepe faza de validare. 3. Sfarsit(Ti), momentul in care Ti si-a terminat faza de scriere.

32. Protocoale bazate pe validare Testul de validare pentru tranzactia Tj cere ca pentru toate tranzactiile Ti cu TS(Ti) < TS(Tj ), una dintre urmatoarele doua conditii sa fie indeplinita: 1. Sfarsit(Ti) < Start(Tj ). Din moment ce Ti isi incheie executia inainte ca Tj sa inceapa, ordinea de serializabilitate este intr-adevar mentinuta. 2. Setul de articole de date scrise de Ti nu se intersecteaza cu setul de articole de date citite de Tj, iar Ti isi incheie faza de scriere inainte ca Tj sa-si inceapa faza de validare (Start(Tj ) <Sfarsit(Ti) < Validare(Tj )). Protejeaza automat impotriva rollback-urilor in cascada- operatiile de scriere propriu-zise au loc doar dupa ce a comis tranzactia care a initiat operatia de scriere. Exista posibilitatea de “infometare”(starvation) a tranzactiilor lungi Aceasta este schema de control al concurentei optimista.

33. Granularitate multipla Sunt circumstante in care ar fi avantajos sa grupam anumite articole de date, si sa le tratam ca o unitate individuala de sincronizare. Este nevoie de un mecanism care sa permita sistemului sa defineasca multiple nivele de granularitate. Articolele de date sa fie de diferite dimensiuni si sa defineasca o ierarhie de granularitati de date, unde granularitatile mai mici se afla in interiorul celor mai mari. Tipuri de noduri :baza de date, arie, fisier, inregistrare. Fiecare nod al arborelui poate fi blocat individual Cand o tranzactie blocheaza un nod, tranzactia a blocat implicit toti descendentii acelui nod in acelasi mod.

34. Granularitate multipla Dar cum determina sistemul daca nodul radacina poate fi blocat? O modalitate eficienta de a obtine aceasta informatie este de a introduce o noua clasa de moduri de blocare numita moduri de blocare de tip intentie (intention lock modes Blocarile de tip intentie sunt puse asupra tuturor stramosilor unui nod inainte ca acesta sa fie blocat in mod explicit. Noi moduri de blocare:intentie-partajat (intention-shared -IS), intentie-exclusiv (intention-exclusive -IX), partajat si intentie-exclusiv (shared and intention-exclusive -SIX) Matricea de compatibilitate

35. Granularitate multipla Fiecare tranzactie Ti poate bloca un nod Q urmand aceste reguli: 1. Trebuie sa observe functia de compatibilitate. 2. Trebuie sa blocheze radacina arborelui mai intai, si il poate bloca in orice mod. 3. Poate bloca un nod Q in modul S sau modul IS doar daca are momentan blocat parintele lui Q fie in modul IX fie in modul IS. 4. Poate bloca un nod Q in modul X, SIX, sau IX doar daca momentan are blocat parintele lui Q blocat fie in modul IX fie in modul SIX. 5. Poate bloca un nod doar daca nu a deblocat anterior un nod (Ti este bifazica). 6. Poate debloca un nod Q doar daca momentan nu are niciunul dintre copii lui Q blocat Acest protocol intensifica concurenta si reduce overheadul blocarii. Este util in mod particular in aplicatiile care includ o combinatie de • Tranzactii scurte care acceseaza doar cateva articole de date. • Tranzactii lungi care produc rapoarte dintr-un intreg fisier sau set de fisiere. Blocajul este posibil in acest protocol, asa cum este posibil si in protocolul bifazic.

36. Scheme multiversiune Fiecare operatie scrie(Q) creeaza o noua versiune a lui Q. Cand o tranzactie initiaza o operatie citeste(Q), managerul de control al concurentei selecteaza una dintre versiunile lui Q pentru citire. Ordonarea stampilelor multiversiune Fiecarei tranzactii Ti din sistem, ii asociem o stampila de timp unica, statica, notata cu TS(Ti). Fiecarui articol de date Q, i se asociaza o secventa de versiuni <Q1, Q2, . . .,Qm>. Fiecare versiune Qk contine trei campuri de date: • Continutul este valoarea versiunii Qk. • W-timestamp(Qk) este stampila de timp a tranzactiei care a creat versiunea Qk. • R-timestamp(Qk) este cea mai mare stampila de timp a tranzactiilor care au reusit sa citeasca cu succes versiunea Qk.

37. Scheme multiversiune Presupunem ca tranzactia Ti initiaza o operatie citeste(Q)sau scrie(Q). Fie Qk versiunea lui Q a carui stampila de scriere este cea mai mare stampila de scriere mai mica sau egala cu TS(Ti). 1. Daca tranzactia Ti initiaza o operatie citeste(Q), atunci valoarea returnata este continutul versiunii Qk. 2. Daca tranzactia Ti initiaza o operatie scrie(Q), si daca TS(Ti)<R-timestamp(Qk), atunci sistemul face rollback tranzactiei Ti. Pe de alta parte, daca TS(Ti) = W-timestamp(Qk), sistemul suprascrie continutul lui Qk; altfel creeaza o noua versiune a lui Q. • Versiunile care nu mai sunt necesare sunt inlaturate . • O cerere de citire nu esueaza niciodata si nu e pusa niciodata sa astepte. • Citirea unui articol de date necesita actualizarea campului R-timestamp, rezultand doua operatii de acces pe disk, in loc de una. • Conflictul dintre tranzactii este rezolvat mai degraba prin rollback decat prin asteptari.

38. Scheme multiversiune Protocolul de blocare bifazica multiversiune Combina avantajele concurentei multiversiune cu avantajele blocarii bifazice. Tranzactiile de actualizare realizeaza o blocare bifazica riguroasa. Stampila de timp nu este o stampila bazata pe un ceas real, ci este un contor . Cand o tranzactie read-only Ti initiaza o operatie citeste(Q), valoarea returnata este continutul versiunii a carei stampila de timp este cea mai mare stampila de timp mai mica sau egala cu TS(Ti). Cand o tranzactie de actualizare citeste un articol de date, obtine o blocare partajata a articolului si citeste ultima versiune a articolului. Cand o tranzactie cu actualizari doreste sa scrie un articol de date, obtine mai intai o blocare exclusiva a articolului, si apoi creeaza o noua versiune a articolului de date. Scrierea este realizata asupra noii versiuni, si stampila de timp a noii versiuni este initial setata la o valoare ∞, o valoare mai mare decat a oricarei stampile de timp. Apoi Ti seteaza stampila de timp a fiecarei versiuni pe care a creat-o la o valoare mai mare cu 1 decat valoarea ts-counter; apoi, Ti incrementeaza ts-counter cu 1. Doar unei tranzactii de actualizare i se permite sa comita la un moment dat.

39. Scheme multiversiune Send on demand In sistemele de baze de date traditionale, elementele de date sunt limitate la calculatorul pe care se afla. In cazul acestui protocol fiecare calculator, care face parte din sistemul de baze de date, intretine o coada de pretentii, pentru fiecare element de date care este localizat in mod curent pe acel calculator. Setul de operatii de acces al tranzactiei este introdus in coada de pretentii al unui calculator in ordionea marcilor de timp ale sosirii tranzactiei. O coada de pretentii, in orice moment de timp, contine un set de tranzactii confirmate si unul de tranzactii neconfirmate. La pornirea sistemului toate elementele de date se afla pe calculatoare oarecare. Fiecare calculator care initiaza o tranzactie asteapta pentru ca intregul set de operatii de acces sa ajunga la locatia lui, termina procesarea tranzactiei si apoi transmite elementele de date la alte calculatoarecare se afla la rand in cozile de pretentii.