Fórum studentů MFF UK

Na předtermínu ve čtvrtek bude prvních pár minut referát o současných MTTF, takže stačí naučit se všechno ostatní :)

Ano, už trochu pozdě:)

Jen k tomu timestamps livelocku - myslím, že ten tvůj příklad není úplně nejlepší, protože pořád se budou objevovat transakce, které úspěšně commitují (čtenáři).

Co takhle:
T1: w(x) w(y)
T2: r(x) r(y)
w1(x1) r2(x1) r2(y0) w1(y1)
zápis w1 je odmítnut (příliš pozdě, r2 má vyšší timestamp a přitom četlo starší verzi) => abortuje se T1, ale T1 již zapsalo x1, kterou četlo r2, takže T2 se musí abortovat taky. Potom pokud scheduler naplánuje stejně, je to livelock.

Asi uz jdu s krizke po funuse, ale treba se to bude nekomu hodit:

[quote="Trupik"]Locking - Exc. 2
Jak může vzniknout deadlock u multiversion plánovače založeném na 2PL?[/quote]

Multiversion planovac zalozeny na 2PL pouziva prave dve verze historie. Jedna je "rozdelana", jedna je commitla - pro cteni.
Pouzivaji se 3 typy zamku - R, W a C(ertified), pricemz R a W spolu nekoliduji, ale C koliduje se vsim. Pri commitu se transakce pokusi upgradovat vsechny W na C.
Priklad historie: RL1(X), R1(X), RL2(Y), R2(Y), WL1(Y), W1(Y), C1 - ceka, az bude moct upgradovat WL(Y) na CL(Y) (tj. az 2. txce pusti RL(Y)), WL2(X), C2 - pokusi se upgradovat WL(X) na CL(X), takze ceka na 1, az ji pustu RL(X). Obe txce na sebe ted cekaji v kruhu ... tj. mame tu deadlock. Reseni je jedine - abortovat jednu z txci.

[quote="Trupik"]Locking - Exc. 2
Timestamp - Exc 2
Jak může vzniknout livelock u multiversion plánovače založeném na timestamps?[/quote]

Livelock = neustale se abortujici transakce. Ke kolizi dojde, pokud se transakce snazi zapsat data, jejich starsi verzi uz cetla mladsi transakce. Napr. mam X verze 5, ktere cetla transakce 7. Transakce 6 tim padem nemuze X zapsat (protoze by psala 6. verzi) a tak je abortovana.
Jednoduchy priklad - mam polozku X, kterou skoro vsichni ctou, ale jen transakce T ji zapisuje. Transakce T navic bezi dlouho (aby spocitala X) a X zapisuje az na konci.
Takze se T rozebehne a zacne pocitat. Mezitim se objevi spousta mladsich transakci, ktere si prectou X. Na konci se T pokusi zapsat X, coz se ji nepovede (protoze uz ho cetli mladsi transakce), tak se abortuje a zkusi to znova. Pokud se ctenari objevuji dostatecne casto, tak se T nikdy nepodari zapsat X.

[quote="Trupik"]Locking - Exc. 2
No a kdyby někdo měl nějaké chytré odpovědi na cvičení v kapitole 7, tak to by bylo taky fajn :wink:[/quote]

1) Transakcni monitor. Obrazek sem asi nenacpu, ale zhruba. TPM (Transaction Processing Monitor) spojuje predevsim spojuje klienty a servery. Klientum umoznuje zakladat a ridit transakce. Pozadavky dispatchuje na servery. Servery jsou typicky startovany on demand a obsahuji pouze business logiku. Servery predavaji pozadavky Resource managerum. Commit (2PC) ridi opet TPM. TPM se stara jeste o dalsi veci - recovery, logging, load balancing (frontovani pozadavku) apod.

2) Doporucuji popsat OTS z CORBA. Viz slajdy 19-SLD-Example-CORBA-OTS.pdf

3) Ja osobne bych tady asi popisoval Activity service. Viz 21-SLD-Example-CORBA-AS.pdf

Mám trochu problém s těmito cvičeními

Locking - Exc. 2
Jak může vzniknout deadlock u multiversion plánovače založeném na 2PL?

Timestamp - Exc 2
Jak může vzniknout livelock u multiversion plánovače založeném na timestamps?

No a kdyby někdo měl nějaké chytré odpovědi na cvičení v kapitole 7, tak to by bylo taky fajn :wink: