Blocare în două fazeEdit
În conformitate cu protocolul de blocare în două faze, o tranzacție își gestionează blocajele în două faze distincte și consecutive în timpul execuției tranzacției:
- Faza de expansiune (cunoscută și ca faza de creștere): se achiziționează blocaje și nu se eliberează niciun blocaj (numărul de blocaje nu poate decât să crească).
- Faza de micșorare (aka faza de contracție): se eliberează încuietori și nu se achiziționează încuietori.
Regula de blocare în două faze poate fi rezumată astfel: nu achiziționați niciodată un încuietor după ce un încuietor a fost eliberat. Proprietatea de serializabilitate este garantată pentru un program cu tranzacții care respectă această regulă.
În mod obișnuit, fără o cunoaștere explicită într-o tranzacție privind sfârșitul fazei 1, se determină în siguranță numai atunci când o tranzacție a finalizat procesarea și a solicitat confirmarea. În acest caz, toate încuietorile pot fi eliberate dintr-o dată (faza 2).
Conservator two-phase lockingEdit
Diferența dintre 2PL și C2PL este că tranzacțiile din C2PL obțin toate încuietorile de care au nevoie înainte de începerea tranzacțiilor. Acest lucru are rolul de a se asigura că o tranzacție care deține deja unele blocaje nu se va bloca în așteptarea altor blocaje. 2PL conservator previne blocajele.
Blocare strictă în două fazeEdit
Pentru a respecta protocolul S2PL, o tranzacție trebuie să respecte 2PL și să elibereze blocajele de scriere (exclusive) numai după ce s-a încheiat, adică după ce a fost fie confirmată, fie anulată. Pe de altă parte, încuietorile de citire (partajate) sunt eliberate în mod regulat în timpul fazei 2. Acest protocol nu este adecvat în B-trees deoarece cauzează Bottleneck (în timp ce B-trees începe întotdeauna căutarea de la rădăcina părinte).
Strong strict two-phase lockingEdit
sau Rigorousness, or Rigorous scheduling, or Rigorous two-phase locking
Pentru a se conforma cu strong strict two-phase locking (SS2PL) protocolul de blocare eliberează atât blocajele de scriere (exclusive) cât și cele de citire (partajate) aplicate de o tranzacție numai după ce tranzacția s-a încheiat, adică, numai după ce a finalizat execuția (este gata) și după ce a fost confirmată sau anulată. Acest protocol respectă, de asemenea, regulile S2PL. O tranzacție care respectă SS2PL poate fi considerată ca având o fază 1 care durează întreaga durată de execuție a tranzacției și nicio fază 2 (sau o fază 2 degenerată). Astfel, nu rămâne de fapt decât o singură fază, iar „două faze” din denumire pare să fie încă utilizată datorită evoluției istorice a conceptului din 2PL, iar 2PL este o superclasă. Proprietatea SS2PL a unui program se mai numește și Rigurozitate. Este, de asemenea, numele clasei de programe care au această proprietate, iar un program SS2PL este numit și „program riguros”. Termenul „Rigurozitate” este lipsit de moștenirea inutilă a termenului „bifazic” și este independent de orice mecanism (de blocare) (în principiu, pot fi utilizate și alte mecanisme de blocare). Mecanismul de blocare al proprietății respective este uneori denumit Rigorous 2PL.
SS2PL este un caz special de S2PL, adică clasa de programe SS2PL este o subclasă proprie a S2PL (fiecare program SS2PL este, de asemenea, un program S2PL, dar există programe S2PL care nu sunt SS2PL).
SS2PL a fost protocolul de control al concurenței ales pentru majoritatea sistemelor de baze de date și utilizat încă de la începuturile lor în anii 1970. S-a dovedit a fi un mecanism eficient în multe situații și oferă, pe lângă serializabilitate, și Strictness (un caz special de Recuperabilitate fără cascadă), care este esențial pentru o recuperare eficientă a bazei de date și, de asemenea, Commitment ordering (CO) pentru participarea în mediile distribuite în care se utilizează o serializabilitate distribuită bazată pe CO și soluții de serializabilitate globală. Fiind un subset al CO, există o implementare eficientă a SS2PL distribuită fără un manager de blocare distribuit (DLM), în timp ce blocajele distribuite (a se vedea mai jos) sunt rezolvate automat. Faptul că SS2PL utilizat în sistemele cu mai multe baze de date asigură serializabilitatea globală este cunoscut de ani de zile înainte de descoperirea CO, dar numai odată cu CO s-a ajuns la înțelegerea rolului unui protocol de angajament atomic în menținerea serializabilității globale, precum și la observarea rezolvării automate a blocajelor distribuite (a se vedea un exemplu detaliat de SS2PL distribuit). De fapt, faptul că SS2PL moștenește proprietățile recuperabilității și ale CO este mai semnificativ decât faptul că este un subset al 2PL, care, în forma sa generală, pe lângă faptul că include un mecanism simplu de serializabilitate (totuși, serializabilitatea este implicată și de CO), nu se știe dacă oferă SS2PL alte calități semnificative. Nu se știe dacă 2PL în forma sa generală, precum și atunci când este combinată cu Strictness, adică Strict 2PL (S2PL), este utilizată în practică. Populara SS2PL nu necesită marcarea „sfârșitului fazei 1”, așa cum o fac 2PL și S2PL, și, prin urmare, este mai simplu de implementat. De asemenea, spre deosebire de 2PL general, SS2PL oferă, așa cum s-a menționat mai sus, proprietățile utile de ordonare Strictness și Commitment.
Există multe variante de SS2PL care utilizează diverse tipuri de blocare cu diverse semantici în diferite situații, inclusiv cazuri de schimbare a tipului de blocare în timpul unei tranzacții. Se remarcă variantele care utilizează blocarea cu granularitate multiplă.
- SS2PL vs. S2PL: Ambele oferă Serializability și Strictness. Deoarece S2PL este o superclasă a SS2PL, poate, în principiu, să ofere mai multă simultaneitate. Cu toate acestea, de obicei nu se observă în practică nici un avantaj de simultaneitate (există exact același tip de blocare pentru ambele, cu o eliberare a blocajului practic nu mult mai devreme pentru S2PL) și nu se justifică sarcina de a se ocupa de un mecanism de sfârșit de fază-1 în S2PL, separat de sfârșitul tranzacției. De asemenea, în timp ce SS2PL asigură ordonarea angajamentelor, S2PL nu o face. Acest lucru explică preferința SS2PL față de S2PL.
- În special înainte de 1990, dar și după, în multe articole și cărți, de exemplu, (Bernstein et al. 1987, p. 59), termenul „Strict 2PL” (S2PL) a fost frecvent definit prin protocolul de blocare „Release all locks only after transaction end”, care este protocolul SS2PL. Astfel, „Strict 2PL” nu ar putea fi acolo numele intersecției dintre Strictness și 2PL, care este mai mare decât clasa generată de protocolul SS2PL. Acest lucru a provocat confuzie. Cu o definiție explicită a S2PL ca fiind intersecția dintre Strictness și 2PL, un nou nume pentru SS2PL și o distincție explicită între clasele S2PL și SS2PL, articolele (Breitbart et al. 1991) și (Raz 1992) au intenționat să clarifice confuzia: primul folosind numele „rigurozitate”, iar al doilea „SS2PL”.”
- Există o proprietate mai generală decât SS2PL (o superclasă de programare), Strict commitment ordering (Strict CO, sau SCO), care la fel de bine asigură atât serializabilitatea, rigurozitatea, cât și CO, și are o supraîncărcare de blocare similară. Spre deosebire de SS2PL, SCO nu se blochează în cazul unui conflict de citire-scriere (un blocaj de citire nu blochează dobândirea unui blocaj de scriere; atât SCO, cât și SS2PL au același comportament în cazul conflictelor de scriere-lectură și scriere-scriere), cu prețul unei posibile întârzieri de confirmare, iar în cazul unui astfel de tip de conflict, SCO are un timp mediu de finalizare a tranzacției mai scurt și o performanță mai bună decât SS2PL. În timp ce SS2PL se supune tabelului de compatibilitate a blocajelor de mai sus, SCO are următorul tabel:
Tip de blocare | read-lock | write-lock |
---|---|---|
read-lock | ||
write-lock | X | X |
Rețineți că, deși SCO eliberează toate încuietorile la sfârșitul tranzacției și respectă regulile de blocare 2PL, SCO nu este un subset al 2PL din cauza tabelului său diferit de compatibilitate a blocajelor. SCO permite conflicte materializate de citire-scriere între două tranzacții în fazele 1 ale acestora, ceea ce 2PL nu permite în faza 1 (a se vedea despre conflictele materializate în Serializability). Pe de altă parte, 2PL permite alte tipuri de conflicte materializate în faza 2 pe care SCO nu le permite deloc. Împreună, acest lucru implică faptul că clasele de planificare 2PL și SCO sunt incomparabile (adică nicio clasă nu conține cealaltă clasă).
Rezumat – Relații între claseEdit
Între oricare două clase de programe (definite prin proprietățile respective ale programelor lor) care au programe comune, fie una o conține pe cealaltă (o conține strict dacă nu sunt egale), fie sunt incomparabile. Relațiile de cuprindere între clasele 2PL și alte clase de orare importante sunt rezumate în următoarea diagramă. 2PL și subclasele sale sunt în mod inerent blocante, ceea ce înseamnă că nu există implementări optimiste pentru acestea (și ori de câte ori se menționează „Optimistic 2PL” se referă la un mecanism diferit cu o clasă care include și programe care nu fac parte din clasa 2PL).
.