Protocoale de blocare la bazele de date - protocolul 2PL centralizat

Protocoale de blocare

In aceasta parte a lucrarii vom prezenta cateva protocoale de blocare in doua faze (2PL) care pot fi folosite pentru a asigura serializabilitatea intr-un sistem distribuit.

Protocoalele de blocare in doua faze au la baza urmatoarele principii:

nici o cerere nu are acces la date daca acestea nu au fost blocate in prealabil (exclusiv sau partajabil);

dupa ce a deblocat unele date, acea cerere nu mai poate bloca nici o alta data.

Cererile de acces pot solicita date situate pe statii diferite din retea. Pentru a superviza executia unor astfel de cereri o statie trebuie sa-si asume rolul de coordonator. Celelalte statii care participa la realizarea cererii se numesc statii cooperante. O statie poate fi in acelasi timp si coordonator (pentru cererile lansate de acolo) si cooperant (pentru cererile lansate de la alte statii care solicita acces la date de pe statia respectiva). Controlul executiei cererii la distanta se realizeaza prin schimb de mesaje (conform unui anumit protocol) intre coordonator si cooperanti.

1 Protocolul 2PL centralizat

Caracteristica acestui protocol este ca exista o singura statie unde se pastreaza informatiile de blocare si unde exista un singur modul care gestioneaza blocarile pentru intreg sistemul distribuit.

Pentru o tranzactie globala initiata la statia S0, 2PL centralizat inseamna urmatoarele:

Coordonatorul cererii de la S₀ imparte cererea in sub-cereri (sub-tranzactii) folosind informatiile din catalogul BDD. Coordonatorul are responsabilitatea de a mentine consistenta BD. Daca tranzactia implica actualizarea unor date care sunt replicate atunci coordonatorul trebuie sa asigure actualizarea tuturor copiilor. De aceea, inainte de a trece la actualizare trebuie blocate toate copiile. Coordonatorul poate alege orice copie pentru a citi date, in general copia de pe statia unde se afla (daca acolo exista una);

Coordonatorul cererii solicita modulului care gestioneaza blocarile, sa blocheze toate datele, impreuna cu copiile lor;

Acest modul verifica daca cererea de blocare este compatibila cu blocarile existente. Daca da, atunci este trimis un mesaj coordonatorului anuntandu-l ca cererea de blocare a fost admisa. Daca nu, cererea este pusa intr-o coada pana cand blocarea poate fi acordata.

Fig. DDBMS cu 2PL centralizat

Avantajele protocolului 2PL-centralizat sunt:

implementarea este relativ simpla;

detectarea blocajelor mortale este simpla, deoarece toate informatiile despre blocare sunt pastrate pe o singura statie.

Dezavantajele acestui protocol sunt:

“inundarea” statiei unde se gaseste modulul care gestioneaza blocarile;

scaderea disponibilitatii sistemului deoarece daca aceasta statie cade atunci intreg sistemul este paralizat.

Tot ca avantaj, putem adauga faptul ca costul comunicarii in retea este relativ scazut: daca tranzactia de actualizare implica n statii atunci sunt necesare minim 2n+3 mesaje:

1 pentru cererea de blocare;

1 pentru acordarea/neacordarea blocarii

n mesaje de actualizare;

n confirmari ale actualizarilor;

1 pentru cererea de deblocare

Proiect: Manual de configurare DC++ Lucrare: Lucrare pentru sustinerea examenului de atestat profesional in informatica - “catalog oriflame” aplicatie programare vizuala

2 Protocolul 2PL- copie principala

Acest protocol incearca sa rezolve unele din problemele protocolului anterior prin distribuirea gestionarii blocarilor pe mai multe statii. Pentru fiecare obiect de date replicat este aleasa o copie principala, celelalte copii numindu-se copii sclav (slave copies). Modulul de gestionare a blocarilor din 2PL-centralizat este divizat in mai multe module care gestioneaza blocari pentru diferite seturi de date.

Principala deosebire intre 2PL-centralizat si 2PL-copie principala este aceea ca atunci cand un obiect de date trebuie actualizat coordonatorul tranzactiei trebuie sa afle carui modul sa-i trimita cererea de blocare. Este necesar sa blocheze la scriere doar copia principala, efectul actualizarii propagandu-se dupa aceea si pentru celelalte copii. Propagarea trebuie facuta cat mai repede posibil pentru a preveni citirile de date neactualizate. Deci, acest protocol garanteaza doar consistenta copiei principale.

Aceasta abordare poate fi folosita atunci cand datele replicate nu sunt intr-o masura foarte mare, actualizarile sunt rare si statiile nu au neaparat nevoie de ultima versiune a datelor ale caror copii sclav le detin.

Dezavantajele acestui protocol sunt:

rezolvarea blocajelor mortale este destul de complexa din cauza multiplelor module care gestioneaza blocarile;

exista, totusi, un grad de centralizare: blocarile pentru o copie principala sunt gestionate de o singura statie.

Acest ultim dezavantaj poate fi depasit desemnand o statie de rezerva pentru a retine informatiile referitoare la blocari.

3 Protocolul 2PL- copie distribuit

Si acest protocol incearca sa rezolve unele dintre problemele protocolului 2PL-centralizat, de data aceasta prin distribuirea unor module de gestionare a blocarilor pentru datele de pe statiile corespunzatoare. Daca datele nu sunt replicate acest protocol este echivalent cu 2PL-copie principala.

Acest protocol este de tipul ROWA (Read-One-Write-All), adica orice copie a unui obiect de date poate fi blocata pentru citire dar toate copiile trebuie blocate pentru scriere.

Fig. DDBMS cu 2PL distribuit

Dezavantajele acestui protocol sunt:

rezolvarea blocajelor mortale este foarte complexa;

costurile comunicatiilor in retea pentru acordarea blocarii sunt foarte mari (5n mesaje).

3 Protocolul blocarii majoritatii

Acest protocol este o extensie a protocolului 2PL-distribuit, extensie care nu necesita blocarea tuturor copiilor unui obiect de date inainte de actualizare.

La fel ca la 2PL-distribuit, exista cate un modul la fiecare statie care gestioneaza blocarile pentru datele de pe acea statie. Atunci cand o tranzactie doreste sa scrie sau sa citeasca un obiect de date care este replicat la n statii, trebuie trimise cereri de blocare la mai mult de jumatate din cele n, nu neaparat la toate. Tranzactia se poate efectua daca a obtinut blocarea din partea majoritatii. Daca nu a primit acordul majoritatii intr-un anumit interval de timp, tranzactia este anulata si toate cele n statii sunt informate despre anulare. Daca, in schimb, primeste acordul majoritatii atunci informeaza toate celelalte statii (dintre cele n) ca detine blocarea.

Dezavantajele acestui protocol sunt:

este foarte complicat de implementat;

rezolvarea blocajelor mortale este foarte complexa;

sunt necesare cel putin mesaje pentru blocare si pentru deblocare;

in cazul blocarii pentru citire este nevoie de acordul majoritatii, pe cand acordul pentru blocarea unei singure copii ar fi de ajuns.

Concluzii

Distribuirea datelor si aplicatiilor prezinta o serie de avantaje potentiale fata de sistemele centralizate traditionale.

Avantaje

1. structura organizationala: adecvata pentru organizatii cu filiale in diferite localitati

2. caracterul partajabil si autonomia locala

disponibilitate crescuta: o pana in cadrul unui site sau o pana a unei linii de comunicatie nu face ca intregul sistem sa devina inoperabil

fiabilitate crescuta: datorita posibilitatii reproducerii datelor in cadrul mai multor site-uri, pana unui nod sau a unei linii de comunicatie nu implica neaparat ca datele sa fie inaccesibile

5. performante imbunatatite: comparativ cu o baza de date situata la distanta, viteza de acces la baza de date distribuita este mai buna, intrucat datele cel mai des accesate sunt localizate in apropierea site-ului cu cea mai mare cerere.

6. economie: este mai eficienta adaugarea de noi statii de lucru intr-o retea decat sa se modernizeze un sistem mainframe

7. dezvoltare modulara: intr-un mediu distribuit este mult mai usor sa se trateze expansiunea: pot fi adaugate site-uri noi, cresterea dimensiunii bazei de date poate fi rezolvata adaugand in retea putere de calcul si de stocare

Dezavantaje

1. complexitate

2. cost: exista costuri continue de comunicatii, datorate utilizarii retelei si costuri de personal care administreaza si intretine sistemele SGBD locale

securitate

control dificil al integritatii

lipsa de standarde

lipsa de experienta: la ora actuala se afla in uz numai cateva SGBDD prototip si specializate

proiectarea mai complexa a BD

Bibliografie

Svetlana Vasileva, Petar Milev, Borislav Stoyanov,2007. Some models of a distributed database management system with data replication. ACM

Preda Ana-Maria,1997.Ghidul Baze de date si sisteme de gestiune a bazelor de date. Bucuresti:Didactica si Pedagogica