[nastava:2003] - Re: evo roka iz baza by "Damjan S. Vujnovic" <damjan@galeb.etf.bg.ac.yu>

E ovako sam ja to shvatio. Mada ne bas do kraja.


G. Damjane i ostali, 

Sve ovo dole odnosi se na poslednji zadatak u januarskom roku iz Baza Podataka, 
ciju je tabelu transakcija Milan vec poslao na grupu.

Molim Vas izjasnite se o ovome, i ako negde gresim, samo recite:

1.   Damjan, Wednesday, February 19, 2003 4:48 PM: 
    When a program needs to access a data item X for the first time, it must execute read(X,xi). All updates to X are then performed on xi. After the program accesses X for the last time, it must execute write(X,xi) in order to reflect the change to X in the database itself.
    The output(X) operation need not take effect immediately after the write(X,xi) is executed, since the block on which X resides may contain other data items that are still being accessed. Thus, the actual output takes place later. Notice that if the system crashes after the write(X,xi) operation was executed but before output(X) was executed, the new value of X is never written to disk and, thus, is lost."

Prvo da usaglasimo sintaksu. Ono što naš cenjeni profesor označava sa X:=X+1 gospoda označavaju sa xi:=xi+1 (menja se samo lokalna kopija), dok je Write(X) ekvivalentno sa Write(X,xi) (upisuje se u deljenu memoriju). I sada ide ključni deo (onaj podvučeni). Gospoda kažu da je ideja cele priče da se u okviru jedne transakcije operacija Write(X,xi) može pojaviti najviše jednom (što je i logično jer nema mnogo smisla u deljenu memoriju upisivati više od jedanput). 

Transakcija T2 ne postuje ovaj protokol. Ona izvrsava Write(A) u trenutku t14, kao i u trenutku t32. 
Ili gresim?

Koliko ja razumem taj prvi Write(X) nema nekog smisla i u principu bi neki transaction manager ili sta vec bi trebalo to da ignorise. To znaci da kada se dobije neki zahtev (query ili vise njih grupisanih u transakciju), query compiler to prevede u interne operacije DBM-a i u principu ignorise vise uzastopnih Write operacija nad istim podatkom.

Na roku bi operacije koje su navedene trebalo da budu bas te interne operacije, predstavljene u citljivom obliku, ali to je samo moja pretpostavka. E sad, zasto ipak imamo dva uzastopna Write(A) ja stvarno ne znam. Da li bi to trebalo da se ignorise ili ne? Kako uopste DBM moze da zna da li ce se javiti jos koja Write operacija pa da ignorise sve osim prve? 
Meni je logicno da query compiler sve to prevede takop da nema vise uzastopnih Write operacija, kao sto sam vec napisao, tako da je meni ipak pitanje sta uopste oznacavaju ove operacije u tabeli???

Damjan (Nikoli):
Tačno, ne poštuje, u tome i jeste "problem", jer teorija kaže da takva transakcija ne bi smela uopšte da se pojavi, naravno ako mi razumemo šta M.B. podrazumeva pod Read(X), Write(X) i X:=X+1

Damjan (Milanu):
Slažem se sa svim što si izneo (još uvek ništa od ukopavanja).

2.  Damjan, Wednesday, February 19, 2003 3:08 PM:
Ako je tabela koju si mi poslao ispravna, onda je redosled serijalizovan i odgovara serijskom redosledu
T5 -> T1 -> T3 -> T2 -> T4
Hint: Razmisli da li baš možeš da primeniš neoznačeni graf! Pogledaj semantiku transakcije. Šta bi se desilo kada bi u transakciji T2 izbacio Read(A)? Suštinski ništa, a ti bi onda rekao da treba primeniti označeni graf. Slično je i sa Read(C) iz T4, ali to sada i nije bitno. 

Kako se nista ne bi desilo? Da bi izvrsila operaciju (t13)::A:=B*2, transakcija T2 mora da dovuce A sa
diska u operativnu memoriju, ili, ako je A vec u operativnoj memoriji, da bar azurira svoju TTS. I jedno i 
drugo radi instrukcija (t12)::Read(A). 
Ili gresim?

Da bi se primenio neoznaceni graf, mora da postoji smisleni Read da se tako izrazim tj. da se ta ucitana vrednost negde i koristi. 

Damjan (Nikoli):
Ne razumem gde vidiš problem. Govorilo se o tome da li je redosled serijalizovan ili nije, to nema nikakve veze sa time kako je implementiran mehanizam za oporavak od kvara. Verovatno sam se pogrešno izrazio, ali moja poenta je da to Read(A) ništa ne doprinosi serijalizovanosti/neserijalizovanosti.

Damjan (Milanu):
Mislim da se i ovde razumemo (za ukopavanje čitaj dalje)...

3.  Damjan, Wednesday, February 19, 2003 3:08 PM:
Ako je tabela koju si mi poslao ispravna, onda je redosled serijalizovan i odgovara serijskom redosledu
T5 -> T1 -> T3 -> T2 -> T4

Da li si siguran? U trenutku t31 transakcija T2 radi G:=G+A, nakon sto je, u trenutku t26, T3 postavila
novu vrednost A (Write(A)). Ovde je u stvari pitanje da li nakon sto T3 izvrsi (t26)::Write(A), T2 azurira
svoj pokazivac na A u tekucoj tabeli stranica? Ako azurira, serijalizovan redosled ne postoji. Ako ne azurira, onda serijalizovan redosled postoji, i to T3 -> T2.
Ili gresim?

Ono sto je mnogo jasnije u oznacavanju koje je primenjeno u Damjanovoj knjizi, a slicno je i u knjizi koju ja imam, a sto ne znam da li je objasnjeno na predavanjima (bio sam samo ne nekom casu vezbi koji je drzao Bojovic i nije to bas objasnio ovako kako ja shvatam), je da sve transakcije kao u principu nezavisni procesi, imaju svoje lokalne kopije podataka. Sto znaci, da svako A:=A+1 se obavlja u memorijskim prostoru jedne transakcije i da to jednostavno ne utice na druge. Odnosno, kada transakcija kaze Read(X) onda uzima tu zajednicku vrednost X i kopira je u svoj lokalni memoriski prostor i sve operacije radi nad njom. Sve dok ne uradi Write(X), ostale transakcije ce sa Read(X) citati tu staru vrednost (pod uslovom, naravno, da niko drugi nije uradio write(X)). 

Tako da bi moj odgovor bio. Kada T3 izvrsi Write(A), azurira se TT3 i nista drugo. 
Damjane, ako gresim, budi fin i nemoj mnogo da me ukopas :) 

Damjan:
Ovo ne želim da komentarišem, jer nije u mom domenu da definišem šta koja operacija radi. Po tom pitanju je moj lični stav isti kao i Milanov, dakle Read(X) inicijalizuje lokalnu kopiju, X:=X+1 menja lokalnu kopiju, Write(X) upisuje lokalnu kopiju u deljenu memoriju. Jedino mi se čini da malo mešate babe i žabe, jer ponavljam serijalizovanost/neserijalizovanost redosleda izvršavanja transakcija nema nikakve veze sa time kako je implementiran mehanizam za oporavak od kvara. Valjda i čitava ideja jeste da ti delovi DBMS-a (Buffer Manager, Concurrency Manager, Recovery Manager, ...) budu lepo razdvojeni (nezavisni, enkapsulirani, kako god, ubi me terminologija). Milanu: pogledaj malo ovu tvoju pretposlednju rečenicu, i seti se Buffer Managera. Ja mislim da se TT3 ne menja, sve ostaje isto, samo se (eventualno) u BAFERU na mesto za A upisuje nova vrednost (mada ja mislim da se čak ni to ne dešava, nego da se menja lokalna kopija promenljive X, pogledaj bre šta si pričao pre N redova). ALI SVE JE OVO NA POGREŠNIM NOGAMA, JER SE OVAKVA TRANSAKCIJA NE MOŽE POJAVITI.

Pozdrav,
Damjan S. Vujnović