Distribuirane Transakcije

Distribuirane transakcije
1.Uvod
2. flat and nested distribuirane transakcije
3. Protokoli atomskog izvrsavanja
4. Kontrola konkurencije u distribuiranim transakcijama
5. Distribuirani zastoj
6. Oporavak transakcije
7. Rezime
Ovo poglavlje predstavlja distribuirane transakcije – one koje ukljucuju vise od jednog servera.
Distribuidane transakcije mogu biti ili flat or nested.
Protokol atomske obaveze je operativna procedura koja se koristi od skupa server ukljucenih u
distribuiranu transakciju.To omogucava serverima da donesu zajednicku odluku o tome da li se
transakcija moze izvrsiti ili prekinuti. Ovo poglavlje opisuje dvofazni protokol za obaveze,
which is the most commonly used atomic commit protocol.
U odeljku o kontroli konkurentnosti u distribuiranim transakcijama govori se o tome kako se

zakljucavanje, odredjivanje vremenskih mera i optimisticka kontrola konkurentosti mogu
produziti za koriscenje sa distirbuiranim transakcijama.
Koriscenje sema zakljucavanja moze dovesti do rasporedjenih blokada. Distribuirane blokade

otkriveni su algoritmi detekcije.
Serveri koji pruzaju transakcije ukljucuju menadzer za oporavak ciji je zabrinutost da se osigura
da se efekti transakcija na objektima kojima upravlja server moze povratiti kada se zameni nakon
otkaza.
Menadzer za oporavak stedi objekte u trajnom skladistu zajedno sa listama namera i

informacijama o status svake transakcije.
13.1 Uvod
U poglavlju 12, smo razgovarali o flat and nested transakcijama koji su postupali objektima na
jednom server. U opstem slucaju, transakcija, bilo da je flag or nested, ce pristupiti objektima
koji se nalaze na nekoliko razlicitih racunara. Koristimo izraz distribuiranu transakciju da
referiramo na flat and nested transakcija koja pristupa objektima kojima upravlja vise server.
Kada se distribuirana transakcija zavrsi, svojstvo atomicnosti transakcija zahteva das vi ukljuceni
server izvrse transakciju ili da svi prekinu transakciju. Da bi se to postiglo, jedan od server
preuzima ulogu koordinatora, sto porazumeva obezbedjivanje istog ishoda na svim serverima.
Nacin na koji coordinator to postize zavisi od izabranog protokola. Protokol koji je poznat kao
dvofazni protokol za obaveze najcesce se koristi. Ovaj protokol omogucava serverima da
komuniciraju jedni s drugima kako bi postigli zajednicku odluku o tome da li ce se izvrsiti ili
prekinuti.
Kontrola konkurentnosti u distribuiranim transakcijama zasniva se na metodama razmatranim u

poglavlju 12. Svaki server primenjuje lokalnu kontrolu konkurencije na svoje objekte, sto
osigurava da se transakcija lokalizuju na lokalnom nivou. Distribuirane transakcije moraju biti
serijalizovani na globalnom nivou. Kako se to postize, varira se od toga da li se koristi
zakljucavanje, odredjivanje vremenske oznake ili optimisticka kontrola konkurencije. U nekim
slucajevima, transakcije se mogu serijalizovati na pojedinacnim serverima, ali u isto vreme moze
doci ciklus zavisnosti izmedju razlicitih server i pojaviti se raspodeljeni mogu se javiti I pojaviti
se raspodeljeni zastoj zakljucak.
Oporavak transakcije se bavi osiguranjem da se svi objekti ukljuceni u transakciju povrate.
Pored toga, u garancijama da vrednosti objekata odrzavaju sve promene izvrsene izvrsenim
transakcijama i nijedna od onoh napravljenih od prekinutih.
1.2 Flat i upletenih distribuirana transakcija
Transakcija klijenta postoje raspodeljiva ako se poziva na operacije u nekoliko razlicitih. Postoje
dva razlicita nacina na koje se mogu distribuirati transakcije: kao flat transakcije i kao
upletenih transakcija.
U flat transakciju, klijent zahteva na vise server. Na primer, na slici 13.1 (a), transakcija T je flat
transakcija koja poziva operacije na objektima na serverima X, Y i Z. A flat klijentska
transakcija ispunjava svaki od svojih zahteva pre nego sto prodje na sledecu. Prema tome, svaka
transakcija pristupa serverima sekvencijalno. Kada server koriste zakljucavanje, transakcija
moze cekati samo jedan objekat istovremeno.
U upletenoj transakciji, transakcija na najvisem nivou moze otvoriti podtransakciju, a svaka

podtransakcija moze otvoriti dalju podtransakciju do bilo koje dubine upletenih.
Slika 13.1 (b) pokazuje transakciju klijenta T koja otvara 2 podtransakcije T1 i T2 koji pritupaju
objektima na serverima X i Y. Podtransakcije T1 i T2 otvaraju dodatne podtransakcije T11, T12,
T21 i T22 koji pristupa objektima na serverima M, N i P. U upletenom slucaj, podtransakcije na
istom nivou mogu istovremeno da se pokrenu, tako da su T1 i T2 istovremeni, a dok pozivaju
objekte na razlicitim serverima, one mogu da rade paralelno. Cetri podtransakcije T11, T12, T21
i T22 takodje pokrecu istovremeno.
-Razmotrite distribuiranu transakciju na koju klijent prenosi $10 sa racuna A do C, a zatim

prenosi $20 od B do D. Racuni A i B se nalaze na odvojenim serverima X i Y, a racuni C i D su
na serverimu Z. Ako je ova transakcija strukturirana kao skup od cetiri upletenih transakcija, kao
sto je prikazano na slici 13.2, cetiri zahteva ( dva depozita i dva povlacenja) mogu se odvijati
paralelno i ukupni efekat se moze postici sa boljim performansama nego jednostavna transakcija
u kojoj se cetiri operacije pozivaju redovno.
Slika 13.2 Nesed bankovna transakcija

Slika 13.3 Distribuirana bankovna transakcija
13.2.1 Koordinator distribuirane transakcije
Serveri koji izvrsavaju zahteve kao deo distribuirane transakcije moraju biti u mogucnosti da
komuniciraju jedni sa drugima kako bi koordinirali svoje radnje kada se transakcija izvrsi.
Klijent zapocinje transakciju slanjem otvorenog zahteva za transakcijom koordinatoru na bilo

kojem serveru, kako je opisano u odeljku 12.2. Koordinator koji je kontaktiran, obavlja otvorenu
transakciju i vraca identifikacioni rezultat transakcije klijentu. Identifikatori transakcija za
distribuirane transakcije moraju biti jedinstveni unutar distribuiranog sistema. Jednostavan nacin
da se to postigne jested a T ID sadrzi dva dela: identifikator server ( na primer, ID adresu )
server koji je kreirao i broj koji je jedinstven za server. Koordinator koji je otvorio transakciju
postaje coordinator za distribuiranu transakciju in a kraju je odgovoran za izvrsenje ili prekid nje.
Svaki od server koji upravlja objektom koji se pristupa transakcijom je ucesnik u transakciji i
obezbedjuje objekat koji zovemo ucesnik. Svaki ucesnik je odgovoran za pracenje svih
nadoplatljivih objekata na tom serveru koji su ukljuceni u transakciju. Ucesnici su odgovorni za
saradnju sa koordinatorom u sprovodjenju protokola o izvrsenju. Tokom napretka transakcije,
koordinator evidentira spisak reference za ucesnike, a svaki ucesnik belezi referencu na
koordinatora.
Interfejs sa koordinatora prikazan na slici 12.3 obezbedjuje dodatni metod, pridruzi se, koji se
koristi kad god novi ucesnik pristupi transakciji .
Koordinator belezi novog ucesnika na listu ucesnika. Cinjenica da koordinator poznaje sve
ucesnike i svaki ucesnik zna koordinator ce im omoguciti da prikupe informacije koje ce biti
potrebne u vreme izvrsavanja.
Slika 13.3 prikazuje klijenta ciji (flat) bankarska transakcija ukljucuje racune. A, B, C i D na
serverima BranchX, BranchY i Branch Z. Transakcija klijenta, T, prenese $4 sa naloga A na
racun C, a zatim prebaci $3 iz naloga B na racun D. Transakcija opisana sa leve strane je
prosirena kako bi pokazala das u otvorena transakcija i bliska transakcija usmereni na
koordinatora, koji bi se nalazio na jednom od server ukljucenih u transakciju. Svaki server se
prikazuje sa ucesnikom koji se pridruzuje transakciji pozivajuci metod pridruzivanja u
koordinatoru. Kada se klijent pozove na jednu od metoda u transakciji, na primer b.povuci(T,3)
objekat koji primi poziv ( B u BranchY u ovom slucaju) informise svog ucesnika da objekat
pripada transakciji T. Ako jos nije obavestio koordinatora, object ucesnika koristi operaciju
pridruzivanja da to ucini. U ovom primeru prikazujemo identifikatora transakcije koji se prenosi
kao dodatni argument, tako da primalac moze da ga prenese na koordinatora. Do trenutka kada
klijent pozove zatvorenu transakciju, koordinator ima preporuke za sve ucesnike.
Imajte na umu da je moguce da ucesnik pozove prekinutu transakciju u koordinatoru ako iz

nekog razloga ne moze da nastavi sa transakcijom.
13.3 Protokoli atomskog izvrsenja

Protokoli za transakciju su izradjeni pocetkom 1970-ih godina, a dvofazni protokol o izvrsenju
pojavio se u Greju 1978. Atomicnost transakcija zahteva da kada se distribuirana transakcija
zavrsi, ili se sve svoje operacije izvrse ili nijedno od njih. U slucaju distribuirane transakcije,
klijent je trazio operacije na vise server. Transakcija se zavrsava kada klijent zatrazi da se
transakcija izvrsi ili prekine. Jednostavan nacin za zavrsetak transakcije na atomski nacin je da
koordinator komunicira sa zahtevom za izvrsenje ili abortiranje svim ucesnicima uranjanju id a
nastavi ponovni zahtev sve dok se ne priznaju svi oni koji su ih izvrsili. Ovo je primer
jednofaznog protokola atomskog izvrsenja.
Ovaj jednostavni jednofazni protokol atomskog izvrsavanja je neadekvatan, jer u slucaju kada
klijent zatrazi obavezu ne dozvoljava serveru da napravi jednostranu odlucku da prekine
transakciju. Razlozi koji sprecavaju server da moze da izvrsi svoj deo transakcije uopsteno se
odnosi na problem kontrole konkurencije. Na primer, ako se koristi zakljucavanje, resenje
zastoja moze dovesti do prekida transakcije bez saznanja klijenta, osim ako ne napravi drugi
zahtev na serveru. Ako se koristi optimisticka kontrola konkurentnosti, neuspeh ispravnosti na
serveru ce dovesti do toga da odluci o transakciji. Koordinator mozda nece znati kada se server
srusio i zamenio tokom napratka distribuirane transakcije – takav server ce morati prekinuti
transakciju. Protokol dvofazne obaveze je dizajniran da omoguci bilo kojem ucesniku da prekine
svoj deo transakcije. Zbog zahteva za atomicnost, ako je jedan deo transakcije prekinut, tada
celokupna transakcija mora biti prekinuta.
U prvoj fazi protokola, svaki ucesnik je glasao za transakciju da bude pocinjena ili obustavljena.
Jednom kada je ucesnik glasao za izvrsenje transakcije, nije mu dozvoljeno da je prekine.
Stoga, pre nego sto ucesnik glasa za izvrsenje transakcije, mora osigurati d ace na kraju moci
izvrsiti svoj deo protokola za izvrsenje, cak i ako to ne uspe i zamenjuje se u medjuvremenu. Za
ucesnika u transakciji se kaze da je u pripremljenom stanju transakciju, ako ce na kraju moci da
je izvrsi. Da bi se uverili u to, svaki ucesnik u trajnom skladistu cuva svoje objekte koje je
izmenio u transakciji, zajedno sa pripremljenim statusom.
U drugoj fazi protokola, svaki ucesnik u transakciji sprovodi zajednicku odluku. Ako bilo koji
ucesnik glasa za prestanak, onda odluka mora da prekine transakciju. Ako svi ucesnici glasaju za
izvrsenje, onda je odluka da se izvrsi transakcija.
Problem je da se osigura das vi ucesnici glasaju id a svi donesu istu odluku. Ovo je prilicno
jednostavno ako se ne dogode nikakve greske, ali protokol mora ispravno raditi cak i kada neki
od server ne uspeju, poruke su izgubljene ili server privremeno nisu u mogucnosti da
komuniciraju jedni sa drugima.
Model za otkazivanje protokola za izvrsenje – Poglavlje 12.1.2 predstavlja model neuspeha za

transakcije koje se jednako primenjuju na dvofazni ( ili bilo koji drugi) protokol za izvrsenje.
Izvrsni protokoli su dizajnirani da rade u asinhroni sistem u kojem server mogu pasti i poruke se
mogu izgubiti. Pretpostavlja se da osnovni protokol za zahtev i odgovor uklanja korumpirane i
duplirane poruke. Nema gresaka u bizantinima- server se srusavaju ili slusaju poruke koje su
poslate. Dvofazni protokol za izvrsenje je primer protokola za postizanje konsenzusa. Poglavlje
11 potvrdjuje da se konsenzus ne moze postici u asinhronom sistemu ako procesu ponekad ne
uspevaju. Medjutim, protokol dvofazne obaveze donosi konsenzus u tim uslovima. Ovo je zbog
toga sto su propusti procesa u slucaju rusenja maskirani zamenom srusenog procesa novim
procesom cije se stanje postavlja iz informacija cuvanih u trajnom skladistu i informacijama koje
drze drugi procesi.
13.3.1 Dvofazni protokol za obaveze

Tokom napretka transakcije, ne postoji komunikacija izmedju koordinatora i ucesnika, osim
ucesnika koji informisu koordinatora kada se prikljuce transakciji. Zahteva klijenta da izvrsi (ili
prekine) transakciju upucuje se koordinatoru. Ako klijent zatrazi da prekine transakciju, ili ako
transakciju prekine jedan od ucesnika, koordinator odmah obavestava ucesnike. Kada klijent
trazi od koordinatora da izvrsi transakciju, stupid u upotrebu protokol dvofazne obaveze.
U prvoj fazi dvofaznog protokola o izvrsenju, koordinator trazi od svih ucesnika ako su spremni
da obavezu, a u drugom, kaze im da izvrse (ili prekinu) transakciju. Ukoliko ucesnik moze
izvrsiti svoj deo transakcije, on ce se sloziti cim se evidentiraju promene i njen status u trajnom
skladistu – i spremna je da izvrsi. Koordinator u distribuiranoj transakciji komunicira sa
ucesnicima da izvrse protokol dvofazne obaveze pomocu operacija sumiranih na slici 13.4.
Metode se mogu izvrsiti, izvrsiti ili prekinuti
Slika 13.4 Izvrsenje operacije za dvofazni protokol
metode u interfejsu ucesnika. Metode su izvrsene i donete su odluke u interfejsu koordinatora.
Dvofazni protokol za izvrsenje se sastoji od faze glasanja i faze zavrsetka kao sto je prikazano na
slici 13.5. Do kraja koraka (2) koordinator i svi ucesnici koji su glasali DA su spremni za
izvrsavanje. Do kraja koraka (3) transakcija je efikasno zavrsena. U koraku (3a) koordinator i
ucesnici su posveceni, tako da koordinator moze prijaviti odluku o obavezivanju klijenta. U
koraku (3b) koordinator obavestava o odluci da prekine klijent. U koraku (4) ucesnici potvrdjuju
da su pocinili tako da koordinator zna kada informacije koje je zabelezio o transakciji vise nisu
potrebne.
Ovaj ocigledno jednostavan protokol bi mogao propasti zbog jednog ili vise server koji se
raspadaju ili zbog razbijanja komunikacije izmedju server. Da bi se resila mogucnost pada, svaki
server cuva informacije koje se odnose na dvofazni protokol za izvrsenje u trajnom skladistenju.
Ove informacije mogu biti preuzete novim procesom koji je zapoceo da zameni sruseni server.
Aspekti oporavka distribuiranih transakcija opisani su u poglavlju 13.6.
Razmena informacija izmedju koordinatora i ucesnika moze biti neuspesna kada jedan od server
pada ili kada se poruka izgubi. Vremenski izlazi se koriste da bi se izbegli procesi blokiranja
zauvek. Kada dodje do nekog vremena u procesu, mora se preduzeti adekvatna akcija. Da bi se
ovo omogucilo, protokol ukljucuje vremenski akciju za svaki korak u kojem process moze
blokirati. Ove akcije su dizajnirane tako da omogucavaju cinjenicu da u asinhtonom sistemu
vremensko izkljucenje mozda ne znaci da je server uspeo.
Akcije isteka u dvofaznom protokolu komande – Postoje razlicite faze protokola kod kojih
koordinator ili ucesnik ne moze napredovati svoj deo protokola dok ne primi novi zahtev ili
odgovor od jedne do drugih.
Slika 13.5 Dvofazni protokol izvrsavanja
Prvo razmislite o situaciji u kojoj je ucesnik glasao Da i ceka koordinatora da izvestava o ishodu
glasanja tako sto ce je obavestiti da je izvrsio ili prekinuo transakciju.
Na slici 13.6. Takav ucesnik nije siguran u ishod i ne moze nastaviti dalje dok ne dobije rezultat
glasanja od koordinatora. Ucesnik ne moze jednostrano odluciti sta dalje da radi, a u
medjuvremenu predmeti koje koristi njegova transakcija ne mogu biti objavljeni za koriscenje od
strane drugih transakcija. Ucesnik na zahtev oducuje koordinatora da odredi ishod transakcije.
Kada dobije odgovor, nastavlja protokol u koraku (4) na slici 13.5. Ako
Slika 13.6 Komunikacija u dvofaznom protokolu za obaveze

koordinator nije uspeo, ucesnik nece moci doneti odluku do zamene koordinatora, sto moze
dovesti do velikih kasnjenja za ucesnike u neizvesnom stanju.
Druge alternativne strategije sun a raspolaganju ucesnicima da dobiju kooperativnu odluku

umesto da kontaktiraju koordinatora. Ove strategije imaju prednost da se mogu koristiti kada
koordinator ne uspe. Pogledaj vezbu 13.5. Medjutim, cak is a protokolom kooperacije, ako su svi
ucesnici u neizvesnom stanju, nece biti u mogucnosti da donesu odluku dok koordinator ili
ucesnik sa znanjem ne bude na raspolaganju. Jos jedna tacka u kojoj se ucesnik moze odloziti je
kada je izvrsio sve svoje zahteve klijenta u transakciji, ali jos nije primio mogucnost izvrsenja,
pozive od koordinatora. Kako klijent salje zatvorenu transakciju koordinatoru, ucesnik moze
otkriti samo takvu situaciju ako primetno u toku odredjene transakcije nije imao dugo vreme, na
primer, vremenski period na bravi. Kako u ovoj fazi nije doneta nikakva odluka, ucesnik moze
odluciti da se nakon odredjenog vremenskog perioda jednostavno ukine.
Koordinator moze biti odlozen kada ceka glasaca od ucesnika. Kako jos nije odluceno o sudbini
transakcije, ona moze odluciti da prekine transakciju nakon odredjenog vremenskog perioda.
On mora tada objaviti prestanak za ucesnike koji su vec poslali svoje glasove. Neki zakasnjeni
ucesnici mogu pokusati da glasaju “da “ nakon toga, ali njihovi glasovi bice ignorisani i on ice
uci u neizvesno stanje kao sto je gore opisano.
Performanse protokola za dvofazno izvrsavanje – Pod uslovom da sve ide dobro – to jest, da
koordinator i ucesnici i komunikacija izmedju njih ne propadnu, protokol dvofaznog izvrsavanja
koji ukljucuje N ucesnike moze se zavrsiti, pomocu koje N moze izvrsiti poruke i odgovore, a
zatim N poruke obazeze. To je cena u porukama proporcionalna 3N, a trosak u vremenu je tri
kruga poruka. Obavezne poruke se ne racunaju u procenjenim troskovima protokolima, koji
mogu pravilno funkcionisati bez njih – njihova uloga je omoguciti serverima da brisu
informacije o zastareloj koordinatoru.
U najgorim slucajevima, moze biti proizvoljno brojnih serverskih i komunikacionih kvarova

tokom dvofaznog protokola izvrsenja. Medjutim, protokol je dizajniran tako da moze tolerisati
nasledje gresaka ( server se srusavaju ili izguvljene poruke) i garantovano je da se zavrsi na
kraju, iako nije moguce odrediti vremenski rok u kojem ce biti zavrsen.
Kao sto je navedeno u odeljku o vremenskim prilikama, protokol dvofazno izvrsenje moze
prouzrokovati znatna odlaganja ucesnika u neizvesno stanje. Ova kasnjenja se javljaju kada
koordinator nije uspeo i ne moze odgovoriti kako bi dobili zahtev za odlucivanje od ucesnika.
Cak i ako kooperativni protokol omogucava ucesnicima da donesu odluke za druge ucesnike,
dodje do odlaganje ako su svi aktivni ucesnici neizvesni.
Protokoli za tri faze su dizajnirane da ublaze takva kasnjenja. Oni su skuplji u broju poruka
potrebnih krugova za normalan ( slucaj bez otkaza ). Za opis izvrsavanja trofaznih protokola
pogledajte vezbu 13.2.
Slika 13.7 Operacije u koordinatoru za upletene transakcije
open SubTransaction(trans) -> subTrans
Otvara novu podtransakciju ciji roditelj je trans i vraca jedinstveni identifikator pretplatnicke
transakcije.
getStatus(trans)->committed, aborted, provisional
Trazi od koordinatora da izvestava o status transakcije trans. Vraca vrednosti koje predstavljaju
jednu od sledecih: pocinjeni, prekinuti, privremeni.
13.3.2 Dvofazni protokol za izvrsavanje upletenih transakcija
Najranija transakcija u nizu upletenih transakcija se naziva transakcija na najvisem nivou.

Transakcije inace: transakcija na najvisem nivou se nazivaju podtransakcijama.
Na slici 13.1(b), T je transakcija na najvisem nivou T1, T2, T11, T12, T21 i T22 su
podtransakcije. T1 i T2 su deca podtransakcije, koji se obracaju njihovim roditeljima. Slicno
tome, T11 i T12 su deca transakcije T1, a T21 i T22 su deca transakcije T2. Svaka
podtransakcija pocinje nakon svog roditelja i zavrsava se pre njega. Tako na primer. T11 i T12
pocinju posle T1 i zavrsavaju se pre njega.
Kada se potpuna transakcija zavrsi, donosi nezvisnu odluku ili da se izvrsi privremeno ili da se
prekine. Privremena izvrsenja nije isto kao sto je priprema: to je samo lokalna odluka i nije
podrzana trajnim skladistenjem. Ako se server kasnije srusi, njegova zamena nece moci izvrsiti
privremeno izvrsenje. Zbog toga je potreban protokol dvofazne obaveze za upletene transakcije
kako bi omogucio serverima privremeno pocinjenih transakcija koje nisu uspele prekinuti.
Koordinator za podtransakciju obezbedice operaciju otvaranja podtransakcije, zajedno sa
operacijom koja omogucava koordinatoru podtransakcije da se raspituje o tome da li je njegov
roditelj jos uvek pocinio ili obustavio, kao sto je prikazano na slici 13.7.
Klijent zapocinje niz upletenih transakcija otvaranjem transakcije najviseg nivoa sa operacijom
otvorene transakcije koja vraca identifikator transakcije za transakciju na najvisem nivou. Klijent
zapocinje podtransakciju pozivom na operaciju otvorene podtransakcije, ciji argument specificira
svoju roditeljsku transakciju. Nova podtransakcija automatski se pridruzuje roditeljskoj
transakciji, a vracen je identifikator transakcije za podtransakciju.
Identifikator za podtransakciju mora biti prosirenje TID-a svojih roditelja, konstruisanih na takav
nacin da identifikator roditeljske ili najviseg nivoa transakcije moze da se odredi iz sopstvenog
identifikatora transakcije.Pored toga, svi identifikatori pretplacanja trebaju biti globalno
jednostavni. Klijent ciji skup upletenih transakcija do kraja, pozivajuci se na blisku transakciju ili
prekinuti transakciju na koordinatoru najvise transakcije.
U medjuvremenu, svaka od ugradjenih transakcija obavlja svoje operacije. Kada su zavrseni,

server koji upravlja podtransakcijom belezi informacije o tome da li je podredovna transakcija
izvrsena privremeno ili prekinuta. Imajte na umu da ako se njegov roditelj prekine, onda ce
podtransakcija biti prisiljena da prekine.
Slika 13.8 Transakcija T odlucuje da li da izvrsi
Podsetimo se poglavlja 12 da se roditelji transakcija- Ukljucujuci i transakciju na najvisem

nivou- moze izvrsiti cak i ako je jedna od njihovih podtransakcija dece prestala. U takvim
slucajevima, roditeljska transakcija ce biti programirana da preduzme razlicite radnje u
zavisnosti od toga da li je podtransakcija izvrsena ili se prekinula. Na primer, razmotrite
bankarsku transakciju koja je dizajnirana da izvrsi sve “ stalne naloge” u filijali na odredjeni dan.
Ova transakcija je izrazena kao nekoliko upletenih prenosnih podtransakcija, od kojih se svaki
sastoji od ugradjenog depozita i povlacenja podtransakcije. Pretpostavljamo da kada je racun
prekoracen, povlaci prekid, a onda se odgovarajuci prenos prekida. Ali nema potrebe za
prekidom celokupnog trajnog naloga samo zato sto prekida podtransakciju transfera. Umesto
prekida, transakcija na najvisem nivou belezi transakcione podtransakcije koje su prekinute i
preduzimaju odgovarajuce radnje.
Razmotrimo transakciju najviseg nivoa T i njegove podtrensakcije prikazane na Slici 13.8, koja
se zasniva na Slici 13.1 (b). Svaka podtransakcija je ili privremeno pocinjena ili obustavljena. Na
primer, T12 je privremeno pocinio i T11 je prekinut, ali T12 zavisi od njenom roditelju T1 i na
kraju na transakciji najviseg nivoa. Iako su T21 i T22 privremeno pocinjeni, T2 je prekinut i to
znaci da T21 i T22 takodje moraju prekinuti. Pretpostavimo da T odluci da izvrsi uprkos
cinjenici da je T2 prekinut, takodje T1 odluci da izvrsi uprkos cinjenici da je T11 prekinuo.
Kada se transakcija na najvisem nivou zavrsi, njegov koordinator obavlja dvofazni protokol za
izvrsenje. Jedini razlog za podtransakciju ucesnika koji nije u mogucnosti da zavrsi jested a li se
stusila od zavrsetka privremenog izvrsenja. Podsetimo se da je, kada je svaka podtransakcija
stvorena, pridruzila se svojom roditeljskoj transackiji. Prema tome, koordinator svake roditeljske
transakcije ima spisak svojih podtransakcija deteta. Kada se upletena transakcija privremeno
obavezuje, prijavljuje svoj status i status svojih potomaka svom roditelju. Kada upletena
transakcija prekine, ona samo prijavljuje prekid svom roditelju bez davanja bilo kakvih
informacija o svojim potomcima. Na kraju, transakcija na najvisem nivou prima listu svih
podtransakcija na stablu, zajedno sa statusaom svake od njih. Potomci prekinutih
podtransakcijama zapravo su izostavljeni sa ove liste.
Informacije koje svaki koordinator poseduje u primeru prikazanom na slici 13.8 prikazane su na
slici 13.9. Imajte na umu da T12 i T21 dele koordinator dok oba pokrecu na serveru N. Kada je
podtransakcija T2 prekinuta, pojavila je cinjenicu njenom roditelju, T, ali bez prenosa bilo
kakvih informacija o svojim podtransakcijama T21 i T22. Podtransakcija je siroce ako jedan od
njegovih predaka prekine, eksplicitno ili zbog toga sto je koordinator srusen.
Slika 13.10 moze izvrsiti? za hijerarhijski dvofazni protokol za obaveze
canCommit? (trans, subTrans) -> Yes/No
Pozovite koordinatora da zatrazite koordinatora decije podtransackije da li moze

izvrsiti podtransakciju subTrans. Prvi argument trans je identifikator transakcije
na najvisem nivou. Ucesnik odgovara svojim glasanjem Da/ Ne.
Slika 13.11 moze izvrsiti? za flat dvofazni protokol
canCommit?(trans, abortList) -> Yes/No
Pozovite od koordinatora do ucesnika da biste zapitali da li moze izvrsiti

transakciju. Ucesnik odgovara svojim glasanjem Da/Ne.
U skladu sa TID u drugim argumentom. Na primer, koordinator T12 je takođe koordinator T21,
jer se pokreću na istom serveru, ali kada primi canCommit? poziv, drugi argument će biti T1 i on
će se baviti samo sa T12. Ako učesnik pronađe bilo koje podtransakcije koje odgovaraju drugom
argumentu, priprema objekte i odgovore sa glasom Da. Ako ne pronađe bilo kakvu, onda se
mora srušiti jer je izvršio pretplatu i odgovorio je bez glasova.
Flat dvofazni protokol za izvrsavanje - U ovom pristupu, koordinator transakcije najvišeg nivoa
šalje canCommit? poruke koordinatorima svih podtransakcija na privremenu listu obaveza. U
našem primeru, koordinatorima T1 i T12. Tokom protokola o izvršenju, učesnici se odnose na
transakciju po TID-u najvišeg nivoa. Svaki učesnik pogleda u svoju listu transakcija za svaku
transakciju ili podtransakciju koja odgovara tom TID-u. Na primer, koordinator T12 je takođe
koordinator T21, jer se pokreću na istom serveru (N).
Nažalost, ovo ne pruža dovoljne informacije kako bi omogućile ispravne radnje učesnika kao što
je koordinator na serveru N koji imaju mješavinu privremeno počinjenih i obustavljenih
podtranskakcija. Ako N koordinator bude upitan samo da izvrši T, završiće se tako što će izvršiti
i T12 i T21, jer su, prema svojim lokalnim informacijama, oba su privremeno posvećena. Ovo je
pogrešno u slučaju T21, jer je njegov roditelj, T2, prekinuo. Da dozvolite takve slučajeve,
canCommit? operacija za protokol ravnog urezivanja ima drugi argument koji daje listu
prekinutih podtransakcijama, kao što je prikazano slika 13.11. Ucesnik moze da učini potomke
transakcije na najvišem nivou, osim ako nisu prekinuli pretke. Kada učesnik primi canCommit?
zahteva, to čini sledeće:
- oni sa prekinutim precima su prekinuti
- pošaljite Da glas koordinatoru.
Ukoliko učesnik nema privremeno prihvaćenog potomaka transakcije na najvišem nivou, on

mora da je propao jer je izvršio transplatansiju i šalje glas Ne koordinatoru.
Nažalost, ovo ne pruža dovoljne informacije kako bi omogućile ispravne radnje učesnika kao što
je koordinator na serveru N koji imaju mešavinu privremeno počinjenih i obustavljenih
podtranskakcija. Ako N koordinator bude upitan samo da izvrši T, završiće se tako što će izvršiti
T12 i T21, jer su, prema svojim lokalnim informacijama, oba privremeno počinjena. Ovo je
pogrešno u slučaju T21, jer je njegov roditelj, T2, prekinuo. Da dozvolite takve slučajeve,
canCommit? operacija za protokol flat izvrsavanja ima drugi argument koji daje listu prekinutih
podtransakcijama, kao što je prikazano na slici 13.11. Učesnik može da učini potomke
transakcije na najvišem nivou, osim ako nisu prekinuli pretke. Kada učesnik primi canCommit?
zahteva, to čini sledeće:
Ako učesnik ima bilo kakve privremeno izvršene transakcije koje su potomci transakcije na
najvišem nivou, trans:
- proverite da nemaju prekinute pretke u abortListu. Zatim se pripremite za izvršenje
(evidentiranjem transakcije i njegovih predmeta u stalnom skladištenju),
-oni sa prekinutim precima se prekidaju;
- pošaljite Da glas koordinatoru.
* Ukoliko učesnik nema privremeno posvećenog potomaka transakcije na najvišem nivou, mora
da je propao, pošto je izvršio pod-transakciju i šalje Koordinatoru “Ne” glas.
Poređenje dva pristupa - hijerarhijski protokol ima prednost da u svakoj fazi učesniku treba samo
potražiti podtransakcije svog neposrednog roditelja, dok je flat protokol trebao imati listu aborta
kako bi eliminisao transakcije čiji su roditelji prekinuti. Moss [1985] je preferirao flat algoritma
jer omogućava koordinatoru transakcije na najvišem nivou da komunicira direktno sa svim
učesnicima, dok hijerarhijska varijanta uključuje prenošenje nizova poruka nizu i gore u fazama.
Pre isteka vremena - Dvofazni protokol za izvršavanje za upletene transakcije može

prouzrokovati odlaganje koordinatora ili učesnika istih tri koraka kao u ne-upletenoj verziji.
Postoji četvrti korak u kome se podtransakcije mogu odložiti. Razmotriti privremeno počinjene
dečije podtransakcije prekinute podtransakcije; neobavezno se obaveštavaju o ishodu transakcije.
U našem primeru, T22 je takva podtranskakcija - ona je privremeno počinila, ali pošto je njen
roditelj T2 prekinut, on ne postaje učesnik. Da bismo se suočili sa takvim situacijama, svaka
podtranskakcija koja nije primila canCommit? poruka će se izvršiti nakon isteka vremenskog
perioda. Operacija getStatus na slici 13.7 dozvoljava suptransakciji da se raspituje da li je roditelj
počinio ili je prekinut. Da bi se takve istrage mogle obaviti, koordinatori prekinute
podtransakcije trebaju preživjeti u određenom periodu. Ako siročna subtranskakcija ne može da
stupi u kontakt sa roditeljima, eventualno će se prekinuti.
13.4 Kontrola paralelnosti u distribuiranim transakcijama
Svaki server upravlja skupom objekata i odgovoran je za osiguranje da ostanu konzistentni kada
se pristupa istovremenim transakcijama. Zbog toga je svaki server odgovoran za primenu
kontrole konkurencije na svoje objekte. Članovi kolekcije servera distribuiranih transakcija su
zajednički odgovorni za obezbeđivanje da su izvršeni na serijski ekvivalentan način.
Ovo podrazumeva da ako je transakcija T pre transakcije U u njihovom konfliktnom pristupu

objektima na jednom od servera onda moraju biti u tom redosledu na svim serverima čiji su
objekti pristupani na suprotan način od strane T i U.
13.4.1 Zaključavanje
U distribuiranoj transakciji, brave na objektu se održavaju lokalno (na istom serveru). Lokalni
menadžer zaključavanja može da odluči da li da odobri zaključavanje ili da izvrši zahtevanu
transakciju. Međutim, ne može da pusti bilo kakve zaključke dok ne zna da je transakcija
izvršena ili prekinuta na svim serverima koji su uključeni u transakciju. Kada se zaključavanje
koristi za kontrolu konkurencije, objekti ostaju zaključani i nedostupni za druge transakcije
tokom protokola atomskog izvršenja, iako prekinuta transakcija oslobađa brave posle faze 1
protokola.
Kako menadžeri zaključavanja na različitim serverima postavljaju svoje brave nezavisno jedan
od drugog, moguće je da različiti serveri mogu nametnuti različite porudžbine na transakcijama.
Transakcija T zaključava objekat A na serveru X, a onda transakcija U zaključava objekat B na

serveru Y. Nakon toga, T pokušava pristupiti B na serveru Y i čeka U-ključ. Slično tome,
transakcija U pokušava da pristupi A na serveru X i mora da čeka T zaključavanje. Zbog toga
imamo T pre U na jednom serveru i U pre T u drugom. Ova različita porudžbina može dovesti do
cikličnih zavisnosti između transakcija i nastale situacije raspodeljene mrtve tačke. Detekcija i
rešavanje distribuiranih blokada govori u sledećem odeljku ovog poglavlja. Kada je otkriven
zastoj, transakcija se prekida radi rešavanja zastoja. U ovom slučaju, koordinator će biti
obavešten i prekinuti transakciju kod učesnika koji su uključeni u transakciju.
13.4.2 Timestamp za kontrolu konkurentnosti

Kod jedne transakcije servera, koordinator izdaje jedinstveni vremenski žig za svaku transakciju
kada započne. Serijska ekvivalencija se primenjuje izvršavanjem verzija objekata po redosledu
vremenskih oznaka transakcija koje su im pristupale. U distribuiranim transakcijama zahtevamo
da svaki koordinator izdaje globalno jedinstvene vremenske oznake. Svetski jedinstveni
vremenski žig transakcije izdaje klijentu prvi koordinator kojem se pristupa transakcijom.
Vremenski žig transakcije se prenese na koordinatora na svakom serveru čiji objekti izvršavaju
operaciju u transakciji.
Serveri distribuiranih transakcija su zajednički odgovorni za obezbeđenje njihovog izvršavanja

na serijski ekvivalentan način. Na primer, ako se verzija objekta kojoj se pristupa transakcijom U
izvršava nakon verzije koju pristupa T na jednom poslužitelju, onda ako T i U pristupe istom
objektu kao i drugi na drugim serverima, moraju ih izvršiti po istom redosledu.
Za postizanje istog porudžbina na svim serverima, koordinatori se moraju složiti oko naručivanja
njihovih vremenskih oznaka. Vremenska oznaka sastoji se od para <local timestamp, server-id>.
Dogovorena porudžbina parova vremenskih oznaka zasnovano je na poređenju u kojem je deo
server-id manji.
Ista porudžbinska transakcija može se postići na svim serverima čak i ako njihovi lokalni satovi
nisu sinhronizovani. Međutim, iz razloga efikasnosti potrebno je da se vremenski žigovi koje
izda jedan koordinator grubo usklađuju sa onima koje izdaju drugi koordinatori. Kada je to
slučaj, naručivanje transakcija generalnoodgovara redosledu započinjanja u realnom vremenu.
Vremenski žigovi se mogu držati grubo sinhronizovanim korišćenjem sinhronizovanih lokalnih
fizičkih časovnika (pogledajte Poglavlje 10).
Kada se naredba za vremensku oznaku koristi za kontrolu konkurencije, konflikti se rešavaju

pošto se vrši svaka operacija. Ako rešavanje sukoba zahtijeva da se transakcija prekine,
koordinator će biti obavešten i on će prekinuti transakciju kod svih učesnika. Stoga, svaka
transakcija koja dostigne zahtev klijenta za izvršenje bi trebala uvek biti u mogućnosti da se
izvrši. Stoga, učesnik u dvofaznom protokolu za obavezivanje obično će pristati na izvršenje.
Jedina situacija u kojoj se učesnik neće složiti da izvrši jeste da se srušio tokom transakcije.
13.4.3 Optimistička kontrola konkurencije

Podsetimo se da je sa optimističkom kontrolom konkurencije svaka transakcija validirana pre
nego što je dozvoljeno izvršiti. Brojevi transakcija se dodjeljuju na početku validacije i
transakcije se serijalizuju prema redosledu transakcijskih brojeva. Distribuiranu transakciju
potvrđuje zbirka nezavisnih servera, od kojih svaka validiše transakcije koje pristupaju
sopstvenim objektima. Validacija na svim serverima se odvija u toku prve faze dvofaznog
protokola.
Razmislite o sledećim prepletima transakcija T i U, koji pristupe objektima A i B na serverima X

i Y, redom.
Transakcije pristupa objektima u redosledu T pre U na serveru X i u porudžbini U pre T na

serveru Y. Sada pretpostavimo da T i U počnu validaciju u približno istom trenutku, ali server X
prvo potvrdi T i server Y validira U prvi. Podsetimo da Poglavlje 12.5 preporučuje
pojednostavljenje protokola validacije koje čini pravilo da samo jedna transakcija može izvršiti
validaciju i ažuriranje faza u isto vreme. Zbog toga svaki server neće biti u mogućnosti da
validira drugu transakciju sve dok prva ne završi. Ovo je primer zastoja zauzetosti.
Pravila validacije u poglavlju 12.5 pretpostavljaju da je validacija brza, što važi za transakcije sa
jednim serverom. Međutim, u distribuiranoj transakciji, protokol dvofaznog izvrsavanja može
potrajati i odložiti druge transakcije da unesu validaciju sve dok se ne dobije rešenje o trenutnoj
transakciji. U distribuiranim optimističkim transakcijama, svaki server primenjuje paralelni
protokol validacije. Ovo je produžetak povratne ili unapred validacije kako bi se omogućilo da
više transakcija bude u fazi validacije istovremeno. U ovom nastavku, treba proveriti pravilo 3,
kao i pravilo 2 za validaciju unazad. To znači da se skup snimanja transakcije koji se validiše
mora proveriti za preklapanja s skupom za pisanje ranijih preklapanja transakcija. Kang i
Robinson [1981] opisuju paralelnu validaciju u svom radu.
Koristi se paralelna validacija, transakcije neće patiti od zastoja u obavezi. Međutim, ako serveri
jednostavno izvršavaju nezavisne potvrde, moguće je da različiti serveri distribuirane transakcije
mogu serijatizovati isti skup transakcija u različitim redosledima, na primer sa T pre U na
serverima X i V pre T na serveru Yu našem primeru.
Serveri distribuiranih transakcija moraju sprečiti da se to dogodi. Jedan pristup je da se posle

lokalnog validiranja od strane svakog servera izvrši globalna validacija [Ceri and Ovicki 19821.
Globalna validacija proverava da li je kombinacija naredbi na pojedinačnim serverima

serijalizibilna; odnosno da transakcija koja je validirana nije uključena u ciklus.
Drugi pristup je da svi serveri određene transakcije koriste isti globalno jedinstveni broj
transakcije na početku validacije [Schlageter 1982J. Koordinator dvofaznog protokola za
izvrsavanje je odgovoran za generisanje globalno jedinstvenog broja transakcije i prosleđuje ga
učesnicima u canCommitu? poruke. Pošto različiti serveri mogu koordinirati različite transakcije,
serveri moraju (kao u protokolu za raspoređivanje vremenskih oznaka) imati dogovorenu
porudžbinu za brojeve transakcija koje generišu.
Agraval et al. [1987] su predložili varijaciju Rung i Robinsonovog algoritma koji podržava
transakcije samo za čitanje, zajedno sa algoritmom koji se zove MVGV (generalizovano
validiranje višestruke verzije). MVGV je oblik paralelne validacije koja osigurava da brojevi
transakcija odražavaju serijski red, ali zahteva da se vidljivost nekih transakcija odloži nakon
izvršenja. Takođe dozvoljava promenu broja transakcije kako bi se omogućilo da neke
transakcije potvrdjuju inače ne bi uspele. Rad takođe predlaže algoritam za izvršavanje
distribuiranih transakcija. Slično je predlogu Schlagetera u tome što se mora naći globalni broj
transakcije. Na kraju faze pročitavanja, koordinator predlaže vrednost za globalni broj
transakcije i svaki učesnik pokušava da potvrdi svoje lokalne transakcije koristeći taj broj.
Međutim, ako je predloženi globalni broj transakcije premali, neki učesnici možda neće moći da
potvrdjuju svoju transakciju i pregovaraju sa koordinatorom za povećan broj. Ako se ne može
naći odgovarajući broj, onda će učesnici morati prekinuti svoju transakciju. Na kraju, ako svi
učesnici mogu potvrditi svoje transakcije, koordinator će dobiti svaku od njih prijedloge za
brojeve transakcija Ako se pronađu uobičajeni brojevi onda će se izvršiti transakcija.
13.5 Rasprostranjeni zastojnici

Diskusija o blokadama u poglavlju 12.4 pokazuje da se blokade mogu pojaviti unutar jednog
servera kada se zaključavanje koristi za kontrolu konkurencije. Serveri moraju ili sprečiti ili
otkriti i rešiti blokade. Korišćenje vremenskih ograničenja za rešavanje eventualnih blokada je
nespretan pristup - teško je odabrati odgovarajući vremenski interval, a transakcije se ne odvode
nepotrebno. Sa šemama otkrivanja blokade, transakcija se prekida samo kada je uključena u
blokadu. Većina šema otkrivanja mrtvih blokova funkcioniše pronalazak ciklusa u grafičkom
čekanju za transakciju. U distribuiranom sistemu koji uključuje više servera kojima se pristupa
više transakcija, globalno čekanje
Slika 13.12 Prekidanje transakcija U, V i W
grafički se u teoriji može konstruisati iz lokalnih. Postoji ciklus u globalnom grafičkom čekanju
koji nije u nekom lokalnom - to jest, može postojati raspodeljeni zastoj. Podsetimo da je grafik
čekanja usmeren graf u kojem čvorovi predstavljaju transakcije i podseća, a ivice predstavljaju
objekat koji drži transakcija ili transakcija čekanja na objekat. Postoji blokada ako i samo ako
postoji ciklus na grafikonu za čekanje.
Na slici 13.12 prikazane su promene transakcija U, V i W koje uključuju objekte A i B kojima

upravljaju serveri X i Y i objekti C i D kojima upravlja server Z.
Kompletni grafik za čekanje na slici 13.13 (a) pokazuje da ciklus zaključavanja sastoji se od
alternativnih ivica, koji predstavljaju transakciju koja čeka objekat i objekat koji drži transakcija.
Pošto svaka transakcija može samo da čeka jedan objekat istovremeno, objekti se mogu ostaviti
van grafikona čekanja, kao što je prikazano na slici 13.13 (b).
Detekcija distribuiranog blokiranog zahteva ciklus koji se može naći u grafičkom čekanju za
globalnu transakciju koja se distribuira među serverima koji su bili uključeni u transakcije.
Lokalni čekati-za grafikonemože da napravi menadžer zaključavanja na svakom serveru, kako je
razmatrano u Poglavlju 12. U prethodnom primeru, lokalni čekovi za grafove servera su:
server U V (added when U requests b. withdraw! JO)) server Z: V —»
W(added when V requests c.withdraw(20)) server X: W —» U (added
when W requests a.withdraw(20))
Kako globalni grafik za čekanje delimično drži svaki od nekoliko uključenih servera,
komunikacija između ovih servera je neophodna za pronalaženje ciklusa na grafikonu.
Jednostavno rešenje je korišćenje centralizovanog otkrivanja zastoja, u kojem jedan server

preuzima ulogu globalnog detektora za zaustavljanje. S vremena na vrijeme, svaki server šalje
najsavremeniju kopiju svog lokalnog grafičkog čekanja na globalni detektor za zaustavljanje,koji
spaja informacije na lokalnim grafikonima kako bi konstruisao globalni grafik za čekanje.
Svetski detektor za zaustavljanje proverava cikluse u globalnom grafikonu čekanja.
Slika 13.13 Distribuirni zastoj
Kada pronadjen ciklus, odlučuje kako rešiti zastoje i obavještava servere o transakciji koja će biti
prekinuta radi rešavanja zastoja.
Centralizovana detekcija zastoja nije dobra ideja, jer zavisi od jednog servera da bi je izvršio. On
pati od uobičajenih problema povezanih sa centralizovanim rešenjima u distribuiranim sistemima
- lošu dostupnost, nedostatak tolerancije grešaka i nemogućnost skale. Pored toga, trošak čestog
prenosa lokalnih grafikona čekanja je visok. Ako se globalni graf se prikuplja manje učestalo,
mrtve tačke mogu trajati duže da se otkriju.
Phantom zatvaranje Q A zastoj koji je "otkriven", ali zapravo nije zastoj, naziva se fantomskom
zastoj. Kod otkrivanja distribuiranog mrtvog ključa, informacije o čekanju odnosa između
transakcija se prenose sa jednog servera na drugi. Ukoliko dođe do mrtve tačke, neophodne
informacije će se eventualno prikupljati na jednom mjestu i otkriti će se ciklus. Budući da će ova
procedura trajati neko vreme, postoji mogućnost da će jedna od transakcija koja ima blokadu u
međuvremenu to pustiti, u tom slučaju zastoj više neće biti.
Razmotrimo slučaj globalnog detektora za zaustavljanje koji prima lokalne grafičke čekanja sa
servera X i Y, kao što je prikazano na slici 13.14. Pretpostavimo da transakcija U onda oslobađa
objekat na serveru X i zatraži onu koju drži V na serveru Y. Pretpostavimo da je i globalni
detektor primio lokalni grafik servera servera prije servera Ks-a. U ovom slučaju bi otkrio ciklus
T - »U V T, iako ivica T -» U više ne postoji. Ovo je primer fantomskog zastoja.
Čitalac posmatrača će shvatiti da ako transakcije koriste dvofazne brave, ne mogu otpuštati
predmete, a zatim dobiti više objekata, a ciklusi fantomskog zastoja se ne mogu pojaviti na način
kako je gore navedeno. Razmotrite situaciju u kojoj ciklus
Slika 13.14 Lokalni i globalni oglasi za čekanje
T - »U -» V -> T je otkriven: ili ovo predstavlja zastoje ili je svaka od transakcija T, U i V

eventualno izvršena. Zaista je nemoguće da se neko od njih obavezuje, jer svaka od njih čeka na
objekat koji nikada neće biti pušten.
Mogućnost otkrivanja fantomskog mrtvog ugla bi se mogla otkriti ako se transakcija čekanja u
ciklusu blokade prekine tokom procedure otkrivanja zastoja. Na primer, ako postoji ciklus T ->
U -> V -> T i U prekida nakon što su sakupljene informacije o U, onda je ciklus već prekinut i
nema zastoja.
Kretanje ivice - Distribuirani pristup otkrivanju blokade koristi tehniku nazvanu obrtanje ivice ili
potiskivanje staze. U ovom pristupu, grafikon za čekanje na globalnom nivou nije konstruisan,
ali svaki uključeni server ima znanje o nekim njegovim ivicama. Serveri pokušavaju pronaći kola
tako što će proslediti poruke zvane proba, koje slijede ivice grafikona kroz distribuirani sistem.
Poruka proba se sastoji od čekanja na transakciji - za odnose koji predstavljaju putanju u
globalnom grafičkom čekanju.
Pitanje je: kada bi server trebao poslati probu? Razmotrite situaciju na serveru X na slici 13.13.
Ovaj server je upravo dodao ivicu W- »U na svoj lokalni grafik za čekanje i u ovom trenutku
transakcija U čeka da pristupi objektu B, koja transakcija V drži na serveru Y. Ova ivica bi
mogla da bude deo ciklusa kao što je V -> T1 -> T2 - V -> U -> V koji uključuje transakcije koje
koriste objekte na drugim serverima. Ovo ukazuje na to da postoji potencijalni distribuirani
ciklus zastoja, koji se može naći s slanjem sonde na server Y.
Sada razmislite o situaciji malo ranije kada je server Z dodao ivicu V - »V na svoj lokalni grafik:
u ovom trenutku VF ne čeka. Stoga, ne bi bilo smisla poslati probu.
Svaka distribuirana transakcija počinje na serveru (nazvan koordinator transakcije) i kreće se na

nekoliko drugih servera (koji se zovu učesnici u transakciji), koji mogu komunicirati sa
koordinatorom. U bilo kom trenutku, transakcija može biti ili aktivna ili čeka na samo jednom od
ovih servera. Koordinator je odgovoran za beleženje da li je transakcija aktivna ili čeka određeni
objekat, a učesnici mogu dobiti ove informacije od svog koordinatora. Menadzeri zaključavanja
informišu koordinate kada transakcije počnu čekati na objektima i kada transakcije stiču objekte
i ponovo postaju aktivne. Kada se transakcija prekine da bi prekinula zaustavljanje, njegov
koordinator će obavestiti učesnike i ukloniti će se svi njegovi zaključci, sa efektom da će svi ivici
koji uključuju tu transakciju biti uklonjeni sa lokalnih grafikona za čekanje.
Slika 13.15 Proba se prenose da bi otkrile zastoje
Iniciranje: Kada server zapazi da transakcija T počne da čeka drugu transakciju U, gde U čeka da
pristupi objektu na drugom serveru, inicira otkrivanje tako što šalje probu koja sadrži ivicu <T -
> U> na server objekat na kojem je transakcija U blokirana. Ako U deli bravu, proba se šalje
svim držačima brave. Ponekad druge transakcije mogu početi deliti bravu kasnije, u kom slučaju
se proba može poslati i njima.
Detekcija: Detekcija se sastoji od primanja probi i odlučivanja o tome da li je došlo do zastoja i

da li se proba prosleđuje.
Na primer, kada server nekog objekta prima probu <T -> U> (koja ukazuje na to da T čeka na
transakciju U koja drži lokalni objekat), ona proverava da li i U čeka. Ako je to, transakcija koju
čeka (na primjer, V) se doda sondi (što ga čini <T-> U -> V>), a ako nova transakcija (V) čeka
na drugi objekt na drugom mjestu, sonda se prosleđuje.
Na ovaj način, staze kroz globalni grafik za čekanje se grade po jednoj ivici istovremeno. Pre
nego što prosledi probu, server proverava da li je transakcija (na primer, T) koja je upravo dodala
izazvala proverivanje da sadrži ciklus (na primer, <T U -> V -> T>). Ako je to slučaj, pronašao
je ciklus u grafikonu i otkriven je zastoj.
Rezolucija: Kada se otkrije ciklus, transakcija u ciklusu je prekinuta da bi se prekinuo otključaj.
U našem primeru, sledeći koraci opisuju kako se otkriva blokada i provere koje se prosleđuju
tokom odgovarajuće faze otkrivanja.
* Server X započinje otkrivanje slanjem probe <W -> U> na server B (Server
Y).
* Server Y prima probu <W -> U>, napominje da je B držao V i dodao V u probu da proizvede
<W -> U -> V>, napominje da V čeka C na serveru Z. Ova proba se prosleđuje na server Z.
*Server Z prima probu <W->U-> V> i napomene C drže W i dodajuW probu da bi proizveli
<W-> U -> V-> W>.
Ova putanja sadrži ciklus. Server otkriva zastoj. Jedna od transakcija u ciklusu mora biti
prekinuta da bi prekinula zaustavljanje. Transakcija koja se može prekinuti može se odabrati
prema prioritetima transakcije, koji će biti opisani uskoro.
Slika 13.15 prikazuje napredak poruke probe od inicijacije od strane servera A do detekcije
blokade od strane servera C. Probe su prikazane kao teške strelice, objekti kao kružic i
koordinatori transakcija kao pravougaoni. Svaka proba je prikazana direktno od jednog objekta
do drugog.U stvarnosti, pre nego što server pošalje probu na drugi server, konsultuje
koordinatora poslednje transakcije na putu da sazna da li drugi čeka drugi objekat na drugom
mestu. Na primer, pre nego što server B prenosi probu <W -> U -> V> konsultuje koordinatora
V da bi se utvrdilo da V čeka C. U većini algoritama za obradu ivice, serveri objekata šalju probe
koordinatorima transakcija, a zatim ih prosleđuju (ako transakcija čeka) na server objekta za
koga se traži transakcija. U našem primeru, server B prenosi probu <W-> U -> V> u koordinator
V, koji ga zatim prosleđuje serveru C. Ovo pokazuje da kada je proba napred, potrebne su dve
poruke.
Gore navedeni algoritam bi trebao pronaći bilo kakav zastoj zaključak koji se javlja, pod
uslovom da transakcije čekanja ne prestaju i ne postoje neuspesi kao što su izgubljene poruke ili
pucanje servera. Da biste to razumeli, razmotrite ciklus zastoja u kojem poslednja transakcija, W,
počinje da čeka i završava ciklus. Kada W počne da čeka objekat, server pokreće probu koja ide
na server objekta koji se drži svake transakcije koju W čeka. Primaoci proširuju i prosleđuju
probu na servere objekata koji zahtevaju sve transakcije čekanja koje pronađu. Stoga svaka
transakcija koju W čeka direktno ili indirektno će biti dodata u prohe ukoliko se ne otkrije
zastoj. Kada postoji zastoj, W čeka na sebe indirektno. Dakle, proba će se vratiti objektu koji W
drži. Stoga svaka transakcija koju čeka direktno ili indirektno će biti dodata u prohe ukoliko se
ne otkrije zastoj. Kada postoji zastoj, W čeka na sebe indirektno. Dakle, sonda će se vratiti
objektu koji W drži.
Izgleda da se veliki broj poruka šalje kako bi otkrio zastoje. U gornjim primerima, vidimo dve
poruke probe za otkrivanje ciklusa koji uključuju tri transakcije. Svaka od probnih poruka je
generalno dve poruke (od objekta do koordinatora, a zatim od koordinatora do objekta).
Sonda koja otkriva ciklus sa N transakcijama će se proslediti koordinatorima transakcija (N- 1)
putem (N- 1) servera objekata, koji zahtijevaju 2 (N - 1) poruke.
Na sreću, većina zastoj blokova uključuje cikluse koji sadrže samo dve transakcije, a nema
potrebe za nepotrebnom zabrinutošću na više poruka. Ovo zapažanje je napravljeno iz studija
baza podataka. Takođe se može reći i uzimajući u obzir verovatnoću konfliktnog pristupa
objektima. Vidi Bernstein et al. 119871.
Slika 13.16 Pokrenute dve probe
Na slici 13.16 (a), uzmite u obzir transakcije T, U, V i W, gde U čeka W i V čeka na T. U

približno istom trenutku, T zahteva objekat koji drži U i W zahteva objekat koji drži V. Dve
odvojene probe <T -> U> i <W -> V> iniciraju serveri ovih objekata i kružiće se do otkrivanja
blokade od strane svakog od dva različita servera. Vidi na slici 13.16 (b), gde je ciklus <T-> U
W -> V -> T> i (c), gde je ciklus <W-> V-> T-> U-> W> .
Da bi se osiguralo da je samo jedna transakcija u ciklusu prekinuta, transakcije se dodeljuju

prioritetima na način da se sve transakcije u potpunosti naruče. Na primer, vremenske oznake
mogu se koristiti kao prioriteti. Kada se pronađe ciklus zatvaranja, transakcija sa najnižim
prioritetom se prekida. Čak i ako nekoliko različitih servera otkrije isti ciklus, svi će dostići istu
odluku o tome koja transakcija će biti prekinuta. Napišemo T> U da pokažemo da T ima veći
prioritet od U. U gornjim primjerima pretpostavimo T> U> V> W. Tada će transakcija V biti
prekinuta kada bilo koji od ciklusa <T-> U-> W - > V-> T> ili <W-> V-> T-> U-> W> je
otkriveno.
Možda se čini da bi se prioriteti transakcija mogli koristiti i za smanjenje broja situacija koje
dovode do otkrivanja mrtvog zatvora, koristeći pravilo da se otkrivanje pokreće samo kada
transakcija višeg prioriteta počne da čeka na niži prioritet. U našem primeru na slici 13.16, kada
bi se T> U poslala inicirajuća sonda <T -> U>, ali kao W <V, inicirajuća proba <W -> V> neće
biti poslata. Ako pretpostavimo da kada transakcija počne da čeka drugu transakciju, jednako je
verovatno da će transakcija čekanja imati viši ili niži prioritet od čekanja za transakciju, onda će
upotreba ovog pravila verovatno smanjiti broj probi za oko polovine .
Prioriteti transakcija takođe se mogu koristiti za smanjivanje broja probi koje se prosleđuju.
Opšta ideja je da probe trebaju putovati "nizbrdo" - to jest, iz transakcija sa većim prioritetima
na transakcije sa nižim prioritetima. Da bi to uradili, serveri koriste pravilo da ne prosleđuju
nikakvu probu nosiocu koji ima veći prioritet od inicijatora. Argument za to je da ako vlasnik
čeka drugu transakciju onda je morao pokrenuti detekciju slanjem probe kada je počela sa
čekanjem.
Slika 13.17 Probe putuju nizbrdo
Međutim, postoji i zamka koja je povezana sa ovim očiglednim poboljšanjima. U našem primeru
na slici 13.15 transakcije U, V i W izvršavaju se u redosljedu u kojem U čeka V i V čeka W kad
W počne da čeka U. Bez prioritetnih pravila, otkrivanje se pokreće kada W počne da čeka
slanjem sonde <W -> U>. Prema pravilu prioriteta, ova proba neće biti poslata, jer W <U i zastoj
neće biti otkrivena.
Problem je u tome što redosled kojim transakcije počinju sa čekanjem mogu utvrditi da li će biti
otkriven zastoj zaključak. Iznad zamku se može izbeći korištenjem šeme u kojem koordinatori
čuvaju kopije svih probi primljenih u ime svake transakcije u redovima probe. Kada transakcija
počne sa čekanjem na objekat, ona prosleđuje probu u svoj red do servera objekta, koji propagira
probe na putu nizbrdo.
U našem primeru na slici 13.15, kada U počne da čeka V, koordinator V će sačuvati sondu <U->
V>. Vidi sliku 13,17 (a). Zatim, kada V počne da čeka W, koordinator W će sačuvati <V-> W> i
V će proslediti svoj red provere <U -> V> do W. Pogledajte sliku 13.17 (b), u kojoj W tip za
proveravanje ima <U -> V> i <V-i W>. Kada W počne da čeka A, to će proslediti njegov red
provere <U -> V -> W> na server A, koji takođe beleži novu zavisnost W - > U i kombinuje je sa
informacijama u probi koja je primljena da bi se utvrdilo da je U -> V -> W -> U. Zastoj je
otkriven.
Kada algoritam zahteva provere koje se čuvaju u redovima provere, takodje zahtijeva aranžmane
za prenošenje provere na nove vlasnike i odbacivanje provere koji se odnose na transakcije koje
su izvršene ili obustavljene. Ukoliko su relevantne provere odbačene, mogu se pojaviti
neotkrivene mrtve tačke i ako se zadrže zastarele provere, mogu se otkriti lažne blokade. Ovo
mnogo doprinosi složenosti bilo kog algoritma. Čitaoci koji su zainteresovani za detalje o takvim
algoritmima bi trebali videti Sinha i Natarajan [1985] i Choudhari et al. [1989], koji predstavljaju
algoritme za upotrebu sa ekskluzivnim bravama. Ali videće da Choudhari et al. pokazali su da je
Sinha i Natarajanov algoritam netačan i ne uspeva da otkrije sve blokade i čak može prijaviti
lažne blokade. Kshemkaliani i Singhal [1991] su ispravili algoritam Choudhari etala. (koja ne
uspeva da otkrije sve blokade i može prijaviti lažne blokade) i obezbediti dokaz ispravnosti
ispravljenog algoritma. U sledećem članku,
Kshemkaliani i Singhal [1994] tvrde da distribuirani blokovi nisu dobro razumljivi jer ne postoji
globalno stanje ili vreme u distribuiranom sistemu. Zapravo, svaki ciklus koji je sakupljen može
sadržati delove snimljene u različito vreme. Pored toga, sajtovi mogu čuti zbog zastoja, ali ne
čuju da su rešeni sve do slučajnih kašnjenja. Rad opisuje raspoređene blokade u smislu sadržaja
distribuirane memorije, koristeći kauzalne veze između događaja na različitim lokacijama.
13.6. Oporavak transakcije

Osobina atomske transakcija zahteva da efekti svih izvršenih transakcija i nijedan od efekata
nepotpunih ili prekinutih transakcija ne odražavaju objekte kojima su pristupali. Ova svojstva se
može opisati u smislu dva aspekta: trajnost i neuspjeh atomnosti. Trajnost zahteva da se objekti
čuvaju u trajnom skladištu i da će biti dostupni na neodređeno vrijeme. Prema tome, potvrda o
zahtevu za izvršenjem klijenta podrazumeva da su svi efekti transakcije zabeleženi u trajnom
skladištenju kao i u objektima (nestabilnim) serverima.Neuspeh atomike zahteva da su efekti
transakcija atomski čak i kada se server sruši. Oporavak se tiče osiguranja da su objekti servera
izdržljivi i da usluga pruža atomsku neuspjeh.
Iako serveri datoteka i serveri baze podataka održavaju podatke u stalnom skladištenju, drugim
vrstama servera povratnih objekata ne treba to učiniti, osim u svrhu oporavka. U ovom poglavlju
pretpostavljamo da kada se pokreće server drži sve svoje objekte u svojoj nestabilnoj memoriji i
evidentira svoje posvećene objekte u datoteku za oporavak ili pločice. Dakle, oporavak se sastoji
od vraćanja servera najnovijim izvršenim verzijama svojih objekata iz trajnog skladištenja. Baze
podataka moraju da se bave velikim količinama podataka. Oni obično drže objekte u stabilnom
skladištenju na disku sa kešom u nestabilnoj memoriji.
Dva zahteva za izdržljivost i atomsku neuspjehu nisu stvarno nezavisni jedna od druge i može se
rešiti samo jednim mehanizmom - menadžerom za oporavak. Zadatak menadžera za oporavak je:
* da sačuvate objekte u trajnom skladištu (u datoteki za oporavak) za izvršene

transakcije;
* da obnovi objekte servera nakon pada;
* da reorganizuje datoteku za oporavak kako bi poboljšala performanse oporavka;
* da povrati prostor za skladištenje (u datoteku za oporavak).
U nekim slučajevima, zahtevamo od menadžera za oporavak da bude otporan na propuste medija

- neuspeh datoteke za oporavak, tako da se neki podaci na disku izgube, bilo da su korumpirani
tokom pada, slučajnim propadanjem ili stalnim neuspehom. U takvim slučajevima potrebna nam
je još jedna kopija datoteke za oporavak. Ovo može biti u stabilnom skladištenju, koji se
implementira tako da je vrlo malo verovatno da ne uspe pomoću ogledatih diskova ili kopija na
drugoj lokaciji.
Lista namera – bilo koji server koji obezbedjuje transakcije mora da čuva praćenje objekta
kojima se pristupa praćenje klijenata. Podsećanje na 12 poglavlje gde su klijenti otvarali
transakcije, server prvo pruža nove transakcije i vraća ih klijentu. Svaki sledeći zahtev klijenta
unutar transakcije uključuje počiniti ili prekinuti zahtev obuhvata identifikovanje transakcije kao
dokaz. U toku napredka transakcije ažurirane operacije su primenjene na privatni skup osetljivih
verzija objekata koji pripadaju transakciji.
Na svakom server , jedna lista namera je zabeležila sve trenutne aktivnosti transakcije - jedna
lista namera posebne transakcije sadrži listu napomena u vrednosti svih objekata koji su
preuredjeni transakcijom. Kada je transakcija posvećena ta transakcija lista namera je korišćena
da identifikuje objekte na koje je to uticalo. Posvećena verzija svakog objekta je ponovljena
probnom verzijom napravljena od te transakcije, i nova vrednost je napisana na datoteku za
oporavak server. Kada transakcija prekida, server koristi listu namera da obriše sve privremene
verzije objekta napravljene od transakcije.
Podsetite in a to da distribuciona transakcija mora da izvrši protocol atomskog izvršenja pre nego
što bude počinjen ili obustavljen. Naša diskusija oporavka je bazirana na dve faze izvršnog
protokola, gde svi učesnici u transakciji najpre kažu šta su spremni da izvrše i kasnije ako su svi
učesnici saglasni, svi oni sprovode stvarno izvršenje akcije. Ako se učesnici ne slože moraće se
prekinuti transakcija.
U trenutku kada učesnik kaže da je pripremljen da izvrši transakciju njegov menađer za oporavak
mora da je sačuvao svoju listu namera za tu transakciju, a predmeti u toj nameri popisuju u
svojoj datoteki za oporavak, tako da će moći izvršiti zadatak transakcije kasnije, čak i ako se u
medjuvremenu srušio.
Kada su svi učecnici uključeni u transakciju saglasni da se to izvrši , kordinator informiše

klijenta i tada šalje poruke učesniku da izvrši svoj deo transakcije. Jednom kada je klijent
informisan tada će se transakcija izvršiti , povratni fajlovi učesnika server moraju sadržati
dovoljne informacije kako bi osigurali da se transakcije izvrše od strane svih server, čak ako
neko od njih ne uspe izmedju pripreme za izvršenje i izvršenje.
Stavke u datoteku za oporavak se bave obnavljenjem servera koji može biti uključen u
distribuiranje transakcija, dodatne informacije pored vrednosti predmeta, su i prodavnica
oporavka. Ove informacije su briga statusa svake transakcije bilo da je izvršeno, odbačeno ili
pripremljeno za izvršenje. Dodatno, svaki objekt u obnavljanju je povezan sa posebnim
transakcijama čuvanjem liste namera u fajl za oporava. Brojka 13,18 pokazuje sumu tipova
ulaza uključeni u datoteku za oporavak
Vrednosti statusa koje se odnose na protokol dvostepenog učešće govori se u odelju 13.6.4 o
oporavku dve faze izvršnog protokola. Mi trebamo sada opisati dva pristupa korišćenja
obnovljivih fajlova: učitavanje i senčenje.
13.6.1 Učitavanje
U tehnici učitavanja datoteka, fajl za oporavak prikazuje istoriju svih transakcija koje izvršava
server.
Slika 13.18 Vrste unosa u datoteku za oporavak

Istorija se sastoji od vrednosti objekta, statusnih transakcija i namera lista transakcija. Redosled
zapisa u dugom odražava redosled u kojem su se transakcije pripremile, izvršile, i prekinule na
serveru. U praksi datoteka za oporavak će sadržati skorašnji snimak vrednosti svih objekata na
serveru, praćene istorijom transakcija nakom snimka.
U toku normalne operacije servera, njegov menađer za oporavak se poziva kad god se transakcija
priprema za prijem, izvršenje ili prekid transakcije. Kada se server sprema za izvršenje
transakcije, menađer za oporavak dodaje sve objekte u listi namera u datoteku za oporavak,
nakon čega sledi status curenja te transakcije zajedno sa njenom listom namera. Kada je
transakcija eventualno izvešena ili odbijena, menađer za oporavak dodaje odgovarajući status
transakcije u datoteku za oporavak. Pretpostavlja se da je operacija dodavanja atomska u smislu
da piše jedan ili više kompletnih unosa u datoteku za recenziju. Ako server ne uspe, samo
poslednji zapis može biti nepotpun. Da bi se efikasnije koristio disk, nekoliko narednih zapisa
može biti bufirirano i zapisano kao samostalno pisno na disku. Dodatna prednost učitavajuće
tehnike kao sekvencijalnog zapisa na disku je brži od zapisa slučajne lokacije. Posle pada, svaka
transakcije neće imati prihvaćen status u dnevniku. Kada je transakcija prihvaćena , njen
prihvaćen status mora biti forsiran na dnevniku koji je , pisan dnevnik zajedno sa svakim drugim
puferiraniom unosu.
Menadjer za oporavak povezuje jedinstveni identifikator sa svakim objektom tako da su

sukcesivne verzije objekta u datoteku oporavka mogu biti povezane sa objektima server. Na
primer, trajni oblik reference na udaljenom objektu, kao što je Corba uporna referenca, uradiće
se kao identifikator objekta.
Figura 13,19 ilustruje dnevnički mehanizan bankarskog servisa transakcija. T i U u figure 12,7.
Dnevnik je uglavnom reorganizovan, ulaz levo dvostruke linije predstavlja fotografiju vrednosti
A,B i C pre započete transakcije T i U. U dinajgamu , mi koristimo imena A,B i C kao
jedinstvenu identifikaciju za objekat. Mi pokazujemo situaciju gde trajsakcija T je izvršena i
transakcija U je pripremljena ali ne i izvršena. Kada se transakcija T pripremi za izvršenje ,
vrednost objekta A i B je zapisana kao pozicija P1 i P2 u dnevniku praćenom statusom
pripremljene transakcije T sa listom namera (<A ,P1>,<B,P2>). Kada transakcija T izvrši,
izvršena transakcija ulaznog statusa za T je stavljena u poziciji P4. Onda kada je transakcija U
Slika 13.19 Prijavite se za bankarske usluge
sprema se da izvrši, vrednosti objekata C i B se pišu na položajima P5 i P6, u prijavljivanju, a

zatim se priprema spremni status transakcije za U sa svojom namerom nabraja {<C, P5>, <B,
P6>}.
Svaki status transakcije sadrži pokazivač na poziciju u datoteku oporavka prethodne unosa
statusa transakcije kako bi omogućio upravniku oporavka da prati stavke statusa transakcije u
obrnutom redosledu kroz datoteku oporavka. Zadnji pokazivač u nizu stavkog statusa transakcije
ukazuje na kontrolnu tacku.
Oporavak objekata - Kada se server zameni posle kvara, prvo postavlja početne vrednosti
početnih vrednosti za svoje objekte, a zatim predaje upravljaču za oporavak. Menadžer za
oporavak je odgovoran za vraćanje objekata servera tako da uključuju sve efekte svih izvršenih
transakcija izvršenih u ispravnom redosledu i nijedan od efekata nepotpunih ili prekinutih
transakcija.
Najnovije informacije o transakcijama su na kraju dnevnika. Postoje dva pristupa za obnavljanje

podataka iz datoteke za oporavak. U prvom slučaju, menadžer za oporavak počinje na početku i
vraća vrednost svih objekata sa najskorijeg kontrolne tracke. Zatim se čita u vrednostima svakog
od objekata, povezuje ih sa njihovim listama namera i za izvršene transakcije zamenjuje
vrednosti objekata. U ovom pristupu, transakcije se ponavljaju po redosledu izvršenja i može ih
biti veliki broj. U drugom pristupu, menadžer za oporavak će vratiti objekte servera tako što će
čitati datoteku za oporavak unazad . Datoteka za oporavak je struktuirana tako da postoji
povratni pokazivač iz svakog unosa statusa transakcije u sledeći. Menadžer za oporavak koristi
transakcije sa statusom obaveze da obnovi one predmete koji još nisu obnavljeni. Nastavlja se
sve dok ne obnovi sve objekte servera. Ovo ima prednost da se svaki objekt vraća samo jednom.
Da biste povratili efekte transakcije, menadžer za oporavak dobija odgovarajuću listu namera iz
datoteke za oporavak. Lista namera sadrži identifikatore i položaje u datoteki oporavka vrednosti
svih objekata pogođenih transakcijom.
Ako server ne uspe na mestu na slici 13.19, njegov menadžer za oporavak će oporaviti objekte na
sledeći način. Počinje na poslednjoj transakciji statusa o prijavljivanju (na P7) i zaključuje da se
transakcija U nije izvršila i da se njegovi efekti ignorišu. Zatim se pomera na prethodni unos
statusa transakcije u prijavu (na P4) i zaključuje da je transakcija T počinila. Da biste povratili
predmete na koje se odnosi transakcija T, pomera se na prethodni unos statusa prijave (na P3) i
pronađe listu namera za T (<A, P1>, <B, P2>). Zatim vraća objekte A i B iz vrednosti u P1 i P
2;. Kako još nije obnovio C, ona se vraća na P0, koja je kontrolna tacka i vraća C.
Da bi pomogao u naknadnoj reorganizaciji datoteke za oporavak, menadžer za oporavak beleže

sve pripremljene transakcije koje nalazi tokom procesa vraćanja objekata servera. Za svaku
pripremljenu transakciju dodaje prekinut status transakcije u datoteku za oporavak. Ovo
osigurava da se u fajlu oporavka svaka transakcija na kraju prikazuje kao celu počinjenu ili
prekinutu.
Server bi ponovo mogao propasti tokom procedure za oporavak. Od suštinskog je značaja da

oporavak bude idempotentan u smislu da se to može učiniti bilo koji broj puta sa istim efektom.
Ovo je direktno pod pretpostavkom da su svi objekti vraćeni na nestabilnu memoriju. U slučaju
baze podataka koja čuva svoje objekte u trajnom skladištenju, sa kešom u nestabilnoj memoriji,
neki od objekata u trajnom skladištu će biti zastareli kada se server zameni posle pada. Zbog
toga, njegov menadžer za oporavak mora vratiti objekte u trajno skladištenje. Ukoliko to ne uspe
tokom oporavka, delimično obnavljeni objekti će i dalje biti tamo. To čini da je idempotencija
malo teže postići.
Reorganizacija pločice za oporavak - Menadžer za oporavak je odgovoran za reorganizaciju

datoteke za oporavak kako bi se brži proces oporavka i smanjio njegovo korišćenje prostora. Ako
se datoteka za oporavak nikada ne reorganizuje, proces oporavka mora pretražiti unazad kroz
datoteku za oporavak dok ne pronađe vrednost za svaki od svojih objekata. Konceptualno, jedina
informacija potrebna za oporavak je kopija posvećenih verzija svih objekata na serveru. Ovo bi
bio najkompaktniji oblik datoteke za oporavak. Kontrolna tacka imena se koristi da se odnosi na
proces pisanja trenutnih izvršenih vrednosti objekata servera u novu datoteku za oporavak,
zajedno sa stavkama statusa transakcija i namerama transakcija koje još uvek nisu u potpunosti
rešile (uključujući informacije povezane sa njima -fazni protokol za obavezivanje). Termin
Kontrolna tačka se koristi da se odnosi na informacije koje se čuvaju u procesu provere. Svrha
postavljanja kontrolnih tacaka je smanjivanje broja transakcija koje treba rešiti tokom oporavka i
povraćaj prostora za datoteke.
Kontrolisanje može se izvršiti odmah nakon oporavka, ali pre početka novih luka. Međutim,
oporavak se možda ne javlja vrlo često. Prema tome, možda će biti potrebno kontrolno tackiranje
s vremena na vreme tokom normalnog rada servera. Kontrolna tačka je upisana u buduću
datoteku za oporavak, a trenutna datoteka za oporavak ostaje u upotrebi sve dok kontrola nije
završena. Kontrolna tačka se sastoji od "dodavanja oznake" u datoteku za oporavak kada
započne kontrolna tacka, pisanje predmeta poslužitelja u buduću datoteku za oporavak, a zatim
kopiranje (1) unosa pre marke koje se odnose na još nerešene transakcije i (2) sve unose nakon
oznaku u datoteku za oporavak u buduću datoteku za oporavak. Kada je kontrolna tačka
popunjena, buduća datoteka za oporavak postaje datoteka za oporavak.
Sistem oporavka može smanjiti upotrebu prostora tako što će odbaciti staru datoteku za
oporavak. Kada menadžer za oporavak izvršava proces oporavka, može se susretati sa
kontrolnim tackama u datoteci oporavka. Kada se ovo desi, može odmah vratiti sve izvanredne
objekte sa kontrolnih tacaka.
Slika 13.20 Senka verzija
Tehnika evidencije evidentira zapise statusa transakcije, liste namera i objekte sve u istoj datoteci
- dnevnik. Tehnika senke verzija je alternativni način organizovanja datoteke za oporavak.
Koristi mapu da locira verzije objekata servera u pločici nazvanu skladište verzija. Mapa
povezuje identifikatore objekata servera sa pozicijama svojih trenutnih verzija u prodavnici
verzije. Verzije koje su napisale svake transakcije su senke prethodnih izdvojenih verzija. Liste
statusa transakcija i liste namera se obrađuju odvojeno. Prvo su opisane senke verzije.
Kada je transakcija spremna za izvršenje, bilo koji od objekata koji su promenjeni za transakciju
dodaju se u skladište verzije, ostavljajući odgovarajuće izvršene verzije nepromenjene. Ove nove
verzije koje se još uvek očekivaju nazivaju se “senke” verzije. Kada se transakcija izvrši, nova
mapa se pravi kopiranjem stare mape i unosom pozicija senke verzije. Da biste dovršili proces
učitavanja, nova mapa zamenjuje staru mapu.
Za vraćanje objekata kada se server zameni nakon pada, njegov menadžer za oporavak čita mapu
i koristi informacije na mapi da locira objekte u prodavnici verzije.
Ova tehnika je ilustrovana sa istim primerom koji uključuje transakcije T i U na slici 13.20. Prva
kolona u tabeli pokazuje mapu pre transakcija T i U, kada su računi A, B i C 100, 200 i 300
USD. Druga kolona prikazuje mapu nakon izvršenja transakcije T.
Prodavnica verzija sadrži kontrolni punkt, a zatim su verzije A i B na P1 i P2 izvršene

transakcijom T. Takođe sadrži senke verzije B i C napravljene transakcijom U, na P3 i P4.
Mapa uvek mora biti upisana na dobro poznato mesto (na primjer, na početku spremišta verzije
ili odvojene datoteke), tako da se može pronaći kada sistem treba da se oporavi.
Prebacivanje sa stare mape na novu mapu mora se izvršiti u jednom atomskom koraku. Da bi se
ovo postiglo, neophodno je da se za mapu koristi stabilno skladištenje, tako da se garantuje
validna mapa čak i kada operacija pisanja datoteka ne uspe. Metoda senke verzija obezbeđuje
brži oporavak od evidencije jer su položaji aktuelnih počinjenih objekata zabeleženi na mapi, a
oporavak iz evidencije zahteva pretraživanje čitavog dnevnika za objekte. Prijavljivanje bi
trebalo biti brže od senskih verzija tokom normalne aktivnosti sistema. To je zato što
prijavljivanje zahteva samo niz operacija dodavanja iste datoteke, dok senke verzije zahtijevaju
dodatno stabilno pisanje (uključujući dva nepovezana blokada diska).
Sama verzija samih nije dovoljna za server koji obrađuje distribuirane transakcije. Unosi statusa
transakcija i liste namera se čuvaju u datoteki koja se zove datoteka statusa transakcije. Svaka
lista namera predstavlja deo karte koji će se promeniti transakcijom kada se izvrši. Datoteka
statusa transakcije može, na primer, biti organizovana kao prijavljivanje.
Donja slika prikazuje mapu i datoteku statusa transakcije za naš trenutni primer kada je T izvršio
i U je spreman da izvrši.
Postoji šansa da se server može srušiti između trenutka kada je registrovan status upisan u
datoteku statusa transakcije i vrijeme ažuriranja mape - u tom slučaju klijent neće biti potvrđen.
Menadžer za oporavak mora dozvoliti ovu mogućnost kada se server zameni nakon pada, na
primer proverom da li su na mapi uključeni efekti poslednje izvršene transakcije u datoteku
statusa transakcije. Ukoliko to nije slučaj, onda se ta druga označava kao prekinuta.
13.6.3 Potreba za statusom transakcija i namerama unosi se u pločicu za oporavak
Moguće je kreirati jednostavnu datoteku za oporavak koja ne uključuje unose za stavke statusa
transakcije i liste namera. Ova vrsta datoteke za oporavak može biti pogodna kada su sve
transakcije usmerene na jedan server. Upotreba stavkog statusa transakcija i namera lista u
datoteci oporavka je od suštinskog značaja za server koji namerava da učestvuje u distribuiranim
transakcijama. Ovaj pristup može biti korisan i za servere ne-distribuiranih transakcija iz
različitih razloga, uključujući sledeće:
* Neki menadžeri za oporavak su dizajnirani da ranije upišu predmete u datoteku za

oporavak - pod pretpostavkom da se transakcije obično vrše.
* Ako transakcije koriste veliki broj velikih objekata, njihova potreba za njihovim
unosom u datoteku za oporavak može komplikovati dizajn servera. Kada se objekti referišu iz
liste namera, oni se mogu naći gde god da se nalaze.
* U vremenskoj kontroli koja vrši kontrolu konkurentnosti, server ponekad zna da će
transakcija na kraju moći da izvrši i potvrđuje klijenta - u ovom trenutku objekti su upisani u
datoteku za oporavak (pogledajte Poglavlje 12) kako bi osigurali njihovu trajnost. Međutim,
transakcija možda mora da čeka da se izvrši dok se ranije transakcije ne izvrše. U takvim
situacijama odgovarajuće stavke statusa transakcija u datoteki oporavka će čekati da se izvrše, a
zatim se obavezuju da osiguraju naredbu za određivanje vremenskih oznaka izvršenih transakcija
u datoteki oporavka, 'datoteka'. Nakon oporavka, bilo koja transakcija čekanja na izvršenje može
se dozvoliti da se izvrši, jer
Slika 13.21 Prijavite se sa unosima koji se odnose na dvofazni protokol za obaveze
oni koji su čekali ili su upravo počinili ili ako ne moraju biti prekinuti zbog neuspeha servera.
13.6.4. Oporavak dvofaznog protokola za izvršenje

U distribuiranoj transakciji svaki server zadržava sopstvenu datoteku za oporavak. Upravljanje
oporavkom opisanim u prethodnom poglavlju mora biti prošireno da bi se bavilo bilo kojim
transakcijama koje obavljaju dvofazni protokol za izvršenje u trenutku kada server ne uspe.
Menadžeri za oporavak koriste dve nove statusne vrijednosti: učinjeno, neizvesno. Ove statusne
vrednosti su prikazane na slici 13.6. Koordinator koristi izvrsavanje da naznači da je ishod
glasanja pozitivan i učinjen kako bi ukazao na to da je dvofazni protokol za obavezivanje
završen. Učesnik koristi neizvesno da naznači da je glasao za Da, ali još uvek ne zna ishod. Dva
dodatna tipa upisa dozvoljavaju koordinatoru da zabeleži listu učesnika i učesnika da beleži svog
koordinatora:
Vrsta unosa Opis sadržaja ulaza
Koordinator Identifikator transakcije, lista učesnika
Identifikator transakcije učesnika, coordinator
U fazi 1 protokola, kada je koordinator spreman da izvrši (i već je dodao pripremljen statusni
unos u datoteku za oporavak), njegov menadžer za oporavak dodaje koordinatni unos u datoteku
za oporavak. Pre nego što učesnik može glasati sa “Da”, mora se već pripremiti za izvršenje
(i mora već dodati pripremljen statusni zapis u datoteku za oporavak). Kada glasuje Da, njegov
menadžer za oporavak beleži unos učesnika i dodaje neizvesni status transakcije u datoteku za
oporavak kao prisilno pisanje. Kada učesnik glasuje Ne, dodaje status prestanak transakcije u
datoteku za oporavak.
U fazi 2 protokola, menadžer za oporavak koordinatora dodaje ili zavedeni ili prekinuti status
transakcije u datoteku za oporavak, prema odluci. Ovo mora biti prisilno pisanje. Menadžeri za
oporavak učesnika dodaju status preuzimanja ili prekidanja statusa transakcije u datoteke za
oporavak prema poruci dobijenoj od koordinatora. Kada koordinator dobije potvrdu od svih
svojih učesnika, njegov menadžer za oporavak dodaje završen status transakcije u datoteku za
oporavak - to ne mora biti prisiljeno. Upisani statusni status nije deo protokola, ali se koristi kada
se datoteka za oporavak reorganizuje. Slika 13.21 prikazuje unose u dnevnik za transakciju T, u
kojoj je server igrao ulogu koordinatora i za transakciju U, u kojoj je server igrao
Slika 13.22 Oporavak od dvofaznog protokola urezivanja
Uloga Status Akcija menadžera za oporavak

Koordinator pripremljen Nije doneta nikakva odluka pre nego što je server uspeo. Ona
šalje prestanak Transakcije na sve servere na listi učesnika i
dodaje status transakcije prekinut u datoteku za oporavak. Ista
akcija za prestanak stanja. Ukoliko nema liste učesnika,
učesnici će vremenom prekinuti i prekinuti transakciju.
Koordinator izvrsen Odluka o izvršenju je postignuta pre nego što je server uspio.
On šalje doCommit svim učesnicima na listi učesnika (u
slučaju da to ranije nije učinio) i nastavlja dvofazni protokol u
koraku 4 (pogledajte sliku 13.5).
Koordinator izvrsen Učesnik šalje poruku koju je poslala koordinatoru (u slučaju
da to nije učinjeno pre nego što je propao). Ovo će omogućiti
koordinatoru da odbije informacije o ovoj transakciji na
sledećem kontrolnom punktu.
Učesnik neizvesno Učesnik nije uspeo pre nego što je znao ishod transakcije. Ne
može utvrditi status transakcije dok koordinator ne obavesti o
odluci. Ona će poslati getDecision koordinatoru da odredi
status transakcije. Kada primi odgovor, on će se izvršiti ili
prekinuti.
Učesnik pripremljen Učesnik još nije glasao i može prekinuti transakciju.
Koordinator Gotovo Nijedna akcija nije potrebna.
uloga učesnika. Za obe transakcije, prvo je uneto stanje transakcije. U slučaju koordinatora sledi
zapis koordinatora i posvećenost statusa transakcije. Urađeni unos statusa transakcije nije
prikazan na slici 13.21. U slučaju učesnika, pripremljeni unos statusa posla prati unos učesnika
čije je stanje neizvesno, a zatim posvećen ili ukinut unos statusa transakcije.
Kada se server zameni posle srušenja, menadžer za oporavak mora da se bavi i dvofaznim
protokolom za uštedu, pored obnavljanja objekata. Za svaku transakciju gde je server igrao ulogu
koordinatora, trebalo bi da pronađe unos koordinatora i skup stavki statusa transakcije. Za bilo
koju transakciju gde je server igrao ulogu učesnika, trebalo bi da pronađe unos učesnika i skup
stavki statusa transakcije. U oba slučaja, najnovija postavka statusa transakcije - to jest ona koja
je najbliža kraju dnevnika određuje status transakcije u trenutku neuspeha. Akcija menadžera za
oporavak u odnosu na protokol dvofazne obaveze za bilo koju transakciju zavisi od toga da li je
server koordinator ili učesnik i njegov status u trenutku neuspjeha, kao što je prikazano na slici
13.22.
Datoteka za reorganizaciju ili oporavak - Morase preduzeti kada vršite kontrolnu tacku kako
biste osigurali da unosi koordinatora bez izvršenog statusa ne budu uklonjeni iz datoteke za
oporavak. Ove unose moraju biti zadržane sve dok svi učesnici ne potvrdjuju da su završili svoje
transakcije. Unosi sa statusom mogu biti odbačeni. Ulazi učesnika sa statusom transakcije
neizvesni moraju takođe biti zadržani.
Oporavak upletenih transakcija - U najjednostavnijem slučaju, svaka subtranskakcija upletene

transakcije pristupa drugom skupu objekata. Pošto se svaki učesnik priprema za izvršenje tokom
protokola za dvofazno izvršenje, piše svoje liste objekata i namera u lokalnu datoteku za
oporavak, povezujući ih sa identifikacijom transakcije na najvišoj transakciji. Iako upletene
transakcije koriste posebnu varijantu protokola za dvofazno izvršavanje, menadžer za oporavak
koristi iste vrednosti statusa transakcije kao i za flat transakcije.
Međutim, oporavak oporavka je komplikovan činjenicom da nekoliko podtranskakcija na istom i

različitom nivou u hijerarhiji upletenih može pristupiti istom objektu. U poglavlju 12.4 opisana
je sema zaključavanja u kojoj roditeljske transakcije nasleđuju brave i podrezne šipke koje
dobijaju brave od roditelja. Šema zaključavanja sili roditeljske transakcije i podtransakcije kako
bi pristupila zajedničkim objektima podataka u različito vreme i osigurava da se pristupi pomoću
istovremenih pod-transakcija na iste objekte moraju serijalizirati.
Objektima kojima se pristupa u skladu sa pravilima upletenih transakcija vrši se nadoknada

obezbeđivanjem različitih verzija za svaku pod-transakciju. Odnos između pretpostavljene
verzije objekta koji se koristi od podtransakcijama upletene transakcije je sličan odnosu između
brava. Da biste podržali oporavak od prekida, server objekta koji deli transakcije na više nivoa
obezbeđuje stub privremenih verzija - po jedan za svaku ugrađenu transakciju koja će se koristiti.
Kada prva pod transakcija u nizu upletenih transakcija pristupi objektu, dobija se obična verzija
koja je kopija trenutne posvećene verzije objekta. Ovo se smatra da je na vrhu stack-a, ali
ukoliko se nekom drugom subtran saetiju pristupi istom objektu, stack se neće materijalizovati.
Kada jedna od njegovih podtranska akcija pristupi istom objektu, ona kopira verziju na vrhu
stack-a i gura u stack. Sve te ispravke podtransakcije primenjuju se na probnu verziju na vrhu
stack-a. Kada se podtransakcija privremeno obavezuje, njena roditeljka nasledi novu verziju. Da
bi se to postiglo, i verzija podtransakcije i verzija njegovog roditelja se odbacuju iz stekla, a
potom nova verzija podtransakcije se vraća u stack (efikasno zamenjuje verziju roditelja). Kada
prekinu transakciju, njegova verzija na vrhu stuba se odbacuje. Na kraju, kada se izvrši
transakcija na najvišem nivou, verzija na vrhu stakla (ako postoji) postaje nova posvećena
verzija.
Na primer, na slici 13.23 pretpostavimo da transakcije T1. T11, T12 i T2 svi pristupaju istom
objektu. A, u redosledu T1; T11; T12 i T2- Pretpostavimo da se njihove probne verzije nazivaju
A1, A11, A12 i A2. Kada T1 počne da se izvršava, A1 se zasniva na posvećenoj verziji A i gurne
se u stack. Kada T11 započne sa radom, bazira svoju verziju A11 na A1 i potiskuje ga na stack,
kada završi, zamenjuje roditeljske
Slika 13.23 Upletene transakcije

verzija na stacku. Transakcije T12 i T2 deluju na sličan način, napokon ostavljajući rezultat T2
na vrhu stuba.
13.7 Rezime
U opštem slučaju, transakcija klijenta će zahtevati rad na objektima na nekoliko različitih
servera. Distribuirana transakcija je svaka transakcija čija aktivnost uključuje nekoliko različitih
servera. Ugrađena struktura transakcija može se koristiti da bi se omogućila dodatna
konkurentnost i nezavisno izvršavanje od strane servera u distribuiranoj transakciji.
Osobina atomičnosti transakcija zahteva da serveri koji učestvuju u distribuiranoj transakciji ili
ih sve učine ili ih sve prekinu. Protokoli atomskog urezivanja su dizajnirani da postignu ovaj
efekat, čak i ako serveri padnu tokom njihovog izvršenja. Dvofazni protokol za obavezivanje
dozvoljava serveru da odluči da se jednostrano prekine. To uključuje i vremenske akcije kako bi
se izbeglo kašnjenja zbog palog servera. Dvofazni protokol za obavezivanje može uzeti
neograničeno vreme za završetak, ali je garantovano da će se na kraju završiti.
Kontrola u distribuiranim transakcijama je modularna - svaki server je odgovoran za

serializabilnost transakcija koje pristupaju sopstvenim objektima. Međutim, neophodni su
dodatni protokoli kako bi se osiguralo da se transakcije serializuju globalno. Distribuirane
transakcije koje koriste porudžbinu za vremensku narudzbinu zahtevaju sredstvo za generisanje
ugovorenog vremenskog narucivanja između više servera. Oni koji koriste optimističku kontrolu
konkurencije zahtevaju globalnu validaciju ili sredstvo za prisiljivanje globalnog naručivanja na
izvršavanje transakcija.
Distribuirane transakcije koje koriste dvofazno zaključavanje mogu patiti od distribuiranih

blokada. Cilj raspoređivanja otkrivenih zastoj blokada je tražiti cikluse u globalnom grafičkom
čekanju. Ako se pronađe ciklus, jedna ili više transakcija mora biti prekinuto kako bi se rešio
zastoj. Ivica chasing je ne-centralizovani pristup detekciji raspoređenih zastoj blokova.
Aplikacije zasnovane na transakcijama imaju jake zahteve za dug vek trajanja i integriteta
podataka koji se čuvaju, ali obično nemaju zahteve za hitnim odgovorima u svakom trenutku.
Protokoli za atomsku vezu su ključ za distribuirane transakcije, ali se ne mogu garantovati da se
završe u određenom vremenskom periodu. Transakcije se čine trajnim izvršavanjem kontrolnih
tacaka i evidentiranjem datoteke za oporavak, koja se koristi za oporavak kada se server zameni
posle pada. Korisnici usluge transakcije će doživeti neka kašnjenja tokom oporavka.
Iako jeste pretpostavljaju da serveri distribuiranih transakcija pokazuju neuspehe i da se pokreću

u asinhroni sistem, oni su u mogućnosti da postignu konsenzus o ishodu transakcija jer se srušeni
serveri zamenjuju novim procesima koji mogu nabaviti sve relevantne informacije iz trajnog
skladištenja ili sa drugih servera .
Vežbe
13.1 U decentralizovanoj varijanti dvofaznog protokola za učešće učesnika komuniciraju
direktno jedni s drugima umesto indirektno putem koordinatora. U fazi 1, koordinator šalje svoj
glas svim učesnicima. U fazi 2, ako glasanje koordinatora nije, učesnici su samo prekinuli
transakciju; ako jeste, svaki učesnik šalje svoj glas koordinatoru i ostalim učesnicima, a svaki od
njih odlučuje o ishodu prema glasanju i izvrsi ga. Izračunajte broj poruka i broj potrebnih
krugova. Koje su njegove prednosti ili mane u poređenju sa centralizovanom varijantom?
13.2 Trofazni protokol za izvršenje ima sledeće delove;
Faza 1: je ista kao za dvofazno izvršenje.

Faza 2: koordinator prikuplja glasove i donosi odluku; ako je ne, prekida i informiše učesnike
koji su glasali Da; ako je odluka Da, šalje preCommit zahtev svim učesnicima. Učesnici koji su
glasali Da čekaju preCommit ili doAbort zahtev. Oni potvrđuju zahteve preCommit-a, i obraćaju
se zahtevima za odbacivanje.
Faza 3; koordinator prikuplja priznanja. Kada su svi primljeni, obavezuje i šalje doCommit
učesnicima. Učesnici čekaju zahtev za doCommit. Kada stigne, počinju.
Objasnite kako ovaj protokol izbegava odlaganje učesnika u svom "neizvesnom" periodu zbog
neuspeha koordinatora ili drugih učesnika. Pretpostavimo da komunikacija nije uspela.
13.3 Objasnite kako dvofazni protokol za izvršenje upletenih transakcija osigurava da ako se
transakcija na najvišem nivou izvrši, svi desni potomci su počinjeni ili obustavljeni.
13.4 Navedite primer preklapanja dve transakcije koje su serijski ekvivalentne svaki server, ali
nije serijski ekvivalentan na globalnom nivou.
13.5 Procedura odluke o getDecision definisana na slici 13.4 obezbeđuju samo koordinatori.
Definišite novu verziju getDecision koju će učesnici obezbediti za korišćenje od strane drugih
učesnika koji treba da dobiju odluku kada koordinator nije dostupan.
Pretpostavimo da bilo koji aktivni učesnik može da napravi zahtev za dobivanje na bilo koji
drugi aktivni učesnik. Da li to rešava problem kašnjenja tokom "neizvesnog" perioda? Objasnite
svoj odgovor. Na koji tačku u protokolu dvofazne obaveze koordinator će obavijestiti učesnike o
identitetima drugih učesnika (kako bi se omogućila ova komunikacija)?
13.6 Proširite definiciju dvofaznog zaključavanja koja se odnosi na distribuirane transakcije.

Objasnite kako je to obezbeđeno distribuiranim transakcijama koristeći striktno dvofazno
zaključavanje na lokalnom nivou.
13.7 Pod pretpostavkom da je u upotrebi striktno dvofazno zaključavanje, opišite kako su

postupci dvofaznog protokola za obaveze povezani sa akcionim kontrolnim akcijama svakog
pojedinačnog servera. Kako se uklapa raspodela otkrivenog distribuiranog ključa?
13.8. Server koristi vremenske narudzbine za lokalnu kontrolu konkurencije. Koje promene
moraju biti napravljene kako bi se prilagodili za korištenje sa distribuiranim transakcijama? Pod
kojim uslovima bi se moglo tvrditi da je dvofazni protokol za obavezivanje redundantan sa
naručivanjem vremenskih oznaka?
13.9 Razmotrite distribuiranu optimističku kontrolu konkurentnosti u kojoj svaki server izvršava
lokalnu naknadnu validaciju sekvencijalno (to jest, sa samo jednom transakcijom u fazi
validacije i ažuriranja u jednom trenutku), u odnosu na vaš odgovor na sliku 13.6. Opišite
moguće ishode kada se dve transakcije pokušaju izvršiti. Kakva je razlika ako serveri koriste
paralelnu validaciju?
13.10 Centralizovani globalni detektor za zaustavljanje drži sindikat lokalnih grafikona za

čekanje. Navedite primer kako biste objasnili kako bi se otkrio fantomski zastoj ako se
transakcija čekanja u ciklusu zastoja prekine tokom procedure otkrivanja blokade.
13.11 Razmotrimo algoritam za obradu ivica (bez prioriteta). Navedi primere kako bi pokazao da
može otkriti fantomske blokade.
13.12 Server upravlja objektima a1, a2 ... an. Obezbeđuje dve operacije za svoje klijente:
Citaj (i) vraća vrednost a1
Piši (i, vrednost) dodeljuje vrednost ai
Transakcije T, U i V su definisane na sledeći način:
T:x=Read(i); Write(j,44);
U:Write(i, 55); Write(j,66);
V:Write(k,77), Write(k,88);
Opišite informacije napisane u evidenciju u ime ove tri transakcije ako se koristi striktno
dvofazno zaključavanje i U stiče ai i aj prije T. Opišite kako će upravitelj za oporavak koristiti
ove informacije da biste povratili efekte T, U i V kada se server zameni nakon pada. Koji je
značaj redosleda unosa komande u log fajlu?
13.13 Dodavanje unosa u datoteku prijavljivanja je atomsko, ali dodati operacije iz različitih
transakcija može se prepletati. Kako to utiče na odgovor na Vežbu 13.12?
13.14 Transakcije T, U i V vežbe 13.12 koriste striktno dvofazno zaključavanje i njihovi zahtevi
se prepliću na sledeći način:
Pod pretpostavkom da upravitelj za oporavak prilagodi unos podataka koji odgovara svakoj
operaciji upisivanja u datoteku prijavljivanja, umesto da čeka do kraja transakcije, opisati
informacije koje su zapisane u datoteku evidencije u ime transakcija T, U i V. Da li je rano
pisanje utiče na tačnost postupka oporavka? Koje su prednosti i mane ranog pisanja?
13.15 Transakcije T i U se pokreću sa kontrolom konkurencije u vremenskom okviru. Opišite

informacije napisane u datoteku evidencije u ime T i U, dozvoljavajući činjenicu da U ima
kasniji vremenski žig od T i mora sačekati da se izvrši nakon T. Zašto je bitno da naredbe za
izvršenje u log fajlu naruče vremenskim žigovima? Opišite efekat oporavka ako se server sruši
(i) između dva Commita i (ii) nakon oboje.
Koje su prednosti i mane ranog pisanja sa naručivanjem vremenskih oznaka?
13.16 Transakcije T i U u Vezbi 13.15 se pokreću sa optimističkom kontrolom konkurencije

koristeći unazad validaciju i ponovno pokretanje bilo koje transakcije koje ne uspeju. Opišite
informacije napisane u evidenciju u njihovo ime. Zašto je neophodno da naredbe za izvršenje u
log fajlu naruče brojevima transakcija? Kako su setovi izvršenih transakcija zastupljeni u log
fajlu?
13.17 Pretpostavimo da se koordinator transakcije sruši nakon što je zabeležio unos liste namera,
ali pre nego što je zabeležio listu učesnika ili poslali canCommit? zahteva. Opišite kako učesnici
rešavaju situaciju. Šta će koordinator uraditi kada se oporavi? Da li bi bilo bolje bilo da snimite
listu učesnika pre unosa liste namera?

Distribuirane Transakcije

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Distribuirane Transakcije

Загружено:

Авторское право:

Доступные форматы

Distribuirane transakcije

2. flat and nested distribuirane transakcije

3. Protokoli atomskog izvrsavanja

4. Kontrola konkurencije u distribuiranim transakcijama

U odeljku o kontroli konkurentnosti u distribuiranim transakcijama govori se o tome kako se

Koriscenje sema zakljucavanja moze dovesti do rasporedjenih blokada. Distribuirane blokade

Menadzer za oporavak stedi objekte u trajnom skladistu zajedno sa listama namera i

Kontrola konkurentnosti u distribuiranim transakcijama zasniva se na metodama razmatranim u

Oporavak transakcije se bavi osiguranjem da se svi objekti ukljuceni u transakciju povrate.

1.2 Flat i upletenih distribuirana transakcija

U upletenoj transakciji, transakcija na najvisem nivou moze otvoriti podtransakciju, a svaka

-Razmotrite distribuiranu transakciju na koju klijent prenosi $10 sa racuna A do C, a zatim

Slika 13.2 Nesed bankovna transakcija

13.2.1 Koordinator distribuirane transakcije

Klijent zapocinje transakciju slanjem otvorenog zahteva za transakcijom koordinatoru na bilo

Imajte na umu da je moguce da ucesnik pozove prekinutu transakciju u koordinatoru ako iz

13.3 Protokoli atomskog izvrsenja

Jednom kada je ucesnik glasao za izvrsenje transakcije, nije mu dozvoljeno da je prekine.

Model za otkazivanje protokola za izvrsenje – Poglavlje 12.1.2 predstavlja model neuspeha za

13.3.1 Dvofazni protokol za obaveze

Slika 13.4 Izvrsenje operacije za dvofazni protokol

metode u interfejsu ucesnika. Metode su izvrsene i donete su odluke u interfejsu koordinatora.

Slika 13.5 Dvofazni protokol izvrsavanja

Slika 13.6 Komunikacija u dvofaznom protokolu za obaveze

Druge alternativne strategije sun a raspolaganju ucesnicima da dobiju kooperativnu odluku

U najgorim slucajevima, moze biti proizvoljno brojnih serverskih i komunikacionih kvarova

Slika 13.7 Operacije u koordinatoru za upletene transakcije

open SubTransaction(trans) -> subTrans

getStatus(trans)->committed, aborted, provisional

13.3.2 Dvofazni protokol za izvrsavanje upletenih transakcija

Najranija transakcija u nizu upletenih transakcija se naziva transakcija na najvisem nivou.

U medjuvremenu, svaka od ugradjenih transakcija obavlja svoje operacije. Kada su zavrseni,

Slika 13.8 Transakcija T odlucuje da li da izvrsi

Podsetimo se poglavlja 12 da se roditelji transakcija- Ukljucujuci i transakciju na najvisem

Slika 13.10 moze izvrsiti? za hijerarhijski dvofazni protokol za obaveze

canCommit? (trans, subTrans) -> Yes/No

Pozovite koordinatora da zatrazite koordinatora decije podtransackije da li moze

Slika 13.11 moze izvrsiti? za flat dvofazni protokol

canCommit?(trans, abortList) -> Yes/No

Pozovite od koordinatora do ucesnika da biste zapitali da li moze izvrsiti

- oni sa prekinutim precima su prekinuti

- pošaljite Da glas koordinatoru.

Ukoliko učesnik nema privremeno prihvaćenog potomaka transakcije na najvišem nivou, on

-oni sa prekinutim precima se prekidaju;

- pošaljite Da glas koordinatoru.

Pre isteka vremena - Dvofazni protokol za izvršavanje za upletene transakcije može

13.4 Kontrola paralelnosti u distribuiranim transakcijama

Ovo podrazumeva da ako je transakcija T pre transakcije U u njihovom konfliktnom pristupu

Transakcija T zaključava objekat A na serveru X, a onda transakcija U zaključava objekat B na

13.4.2 Timestamp za kontrolu konkurentnosti

Serveri distribuiranih transakcija su zajednički odgovorni za obezbeđenje njihovog izvršavanja

Kada se naredba za vremensku oznaku koristi za kontrolu konkurencije, konflikti se rešavaju

13.4.3 Optimistička kontrola konkurencije

Razmislite o sledećim prepletima transakcija T i U, koji pristupe objektima A i B na serverima X

Transakcije pristupa objektima u redosledu T pre U na serveru X i u porudžbini U pre T na

Serveri distribuiranih transakcija moraju sprečiti da se to dogodi. Jedan pristup je da se posle

Globalna validacija proverava da li je kombinacija naredbi na pojedinačnim serverima

13.5 Rasprostranjeni zastojnici

Slika 13.12 Prekidanje transakcija U, V i W

Na slici 13.12 prikazane su promene transakcija U, V i W koje uključuju objekte A i B kojima

Jednostavno rešenje je korišćenje centralizovanog otkrivanja zastoja, u kojem jedan server

Slika 13.13 Distribuirni zastoj

Slika 13.14 Lokalni i globalni oglasi za čekanje