Prvo mi je promakao tvoj odgovor, a onda sam imao posla pa nisam stigao da ti odgovorim (cisto da ne ispadne kako sam neazuran). E, a sad, idemo redom...
Prvo, trudicu se da izbegavam konstrukcije tipa "nije dozvoljen" i sl. U ovom slucaju je sasvim opravdano (barem po mom misljenju) da neke stvari ne dozvolis (objasnjenje ispod).
Za pocetak, posto vidim da povremeno u pricu ubacujes korisnika, onog koji pise transakciju, i da ti "smeta" kada neko ogranicava njegovu slobodu prilikom pisanja istih - moracu da se blago ne slozim sa tobom. Naime treba uociti da ovde postoje dva nivoa - jedan (nazovimo ga deklarativni) - to je onaj na kome se nalazi korisnik, i drugi (hajde neka bude fizicki, nije bas najsrecniji izbor, ali mi nista pametnije ne pada na pamet) - to je onaj na kome deluje transaction manager (deo DBMS-a odgovoran za, logicno, podrsku transakcijama). Na primer, deklarativni nivo je SQL (insert, update, select), dok na tom fizickom nivou postoje Read(X) i Write(X). Strasno je ocigledno (barem meni) da je svaku transakciju implementiranu na deklarativnom nivou, moguce implementirati i na fizickom a da se pri tome postuje sledeci skup pravila (ili ogranicenja kako ih ti zoves; imaj u vidu da za transakciju mora da vaze ACID osobine tako da eventualni "kontraprimeri" sa konkurentnim neserijalizovanim transakcijama nece biti uvazeni
):
- u okviru jedne transakcije ne moze da bude "Write(X), pa Read(X)" (citiram tebe, ja sam razumeo na sta si mislio) - naprosto transakcija moze da sacuva lokalnu kopiju X-a pa nema potrebe da je cita.
- "read(X) vise puta u jednoj transakciji nije dozvoljen" - isti argument kao i gore.
Dakle, u okviru DBMS-a postoji modul koji je odgovoran za pretvaranje iz npr.
SELECT u gomilu
Read-ova i
UPDATE u gomilu
Write-ova i ciji je zadatak da formira transakciju na fizickom nivou i preda je transaction manager-u.
Btw, nisam shvatio na sta si ciljao sa ona dva linka (
www.cs.yale.edu) - posto se Open Office nije izborio sa ukazivacima, pa te molim da mi das ili copy&paste relevantnih delova ili da mi kazes na kojoj tacno strani da gledam (za lock conventions mislim da sam otisao na pravo mesto, ali ne vidim problem).
Dakle, ja i dalje ostajem da pri tome da kada Silberschsatz kaze,
After last access, transaction executes write(X) misli da moze postojati najvise jedan Write(X) po transakciji (prosto je covek tako definisao pravilno formiranu transakciju - sto ne znaci da je nije moguce definisati i na neki drugi nacin).
Zasto se ovo meni cini vazno? Pa iz prostog razloga sto ovim ogranicenjima (skoro) nista ne gubis, a mnogo dobijas. Laksa analiza (manje bitno) i manja mogucnost nastanka neserijalizovanih redosleda izvrsavanja.
Ovo je dakle bila moja argumentacija zbog cega jedna transakcija "ne bi smela" da ima vise od jednog Write(X).
Ali sve ovo, sa druge strane, i nije vazno za citavu ovu pricu jer se 100% slazem da algoritam prof. Bojovica za oznaceni graf redosleda nije ispravan.
I love the smell of copyright violations in the morning. Smells like... freedom!
Trazim strucnjake iz Upravljanja Transakcijama
Re: Trazim strucnjake iz Upravljanja Transakcijama
) i uocio jedno klizavo mesto. Tacka 7, transakcija T1. Ako se vec drzis Silberschsatz-a, tvoja transakcija nije regularna (ili koristis drugaciju notaciju - nepravilnu (ili barem ne sasvim definisanu, blaze receno) - poput one profesora Bojovica). Naime, ni jedna transakcija ne moze da ima dva Write-a (pogledaj Silberschsatz-a; opet kazem to vazi za njegovu notaciju) - uvek radi sa lokalnom kopijom podatka, a Write (koji upisuje u deljeni prostor) ide samo jednom, i to nakon poslednje modifikacije lokalne kopije. U Silberschsatz-u ide nesto tipa (notacija verovatno nije 100% kompatibilna sa Silberschsatz-ovom, ovo pisem iz glave, sa posla gde nemam knjigu):
