Transakce Petr Tůma petr.tuma@mff.cuni.cz http://nenya.ms.mff.cuni.cz/~ceres/txy/main.php maillist, wiki zkouška: bodovaná písemka, polovina zhruba stačí na trojku zdroje Grey, Reuter: Transaction Processing Bernstein: Concurrency Controls... (na webu v PDF) http://nenya.ms.mff.cuni.cz/~prochazk/lectures/tp000529.pdf tohle (sepsal Petr Novák; opravy Přemek Paška; http://urtax.ms.mff.cuni.cz/~novap2am/poznamky/) K čemu transakce původně v high availability systémech transakce intuitivně - jednotková operace nad daty požadavky: spolehlivost, dostupnost, výkon, odezva, trvalost, atomicita, distribuovanost, škálovatelnost dobře definovaná abstrakce jsou v tom peníze ACID Atomicity (všechno nebo nic, commit/abort, problémy s reálnými akcemi; kompenzující transakce - místo abortu, zkažené věci koriguje -- třeba rozvod) Consistency (zachová konzistentní stav; starost programátora, ne systému) Isolation (současně běžící transakce se navzájem neovlivňují) Durability Transaction Processing Monitor balík pro transakce (podpora pro aplikace, etc) Spolehlivost expected (defined, specified) behavior observed behavior rozdíl = chyba "fault" = chyba v návrhu, může způsobit "error" (chybný stav za běhu), který může způsobit "failure" (selhání viditelné zvenčí) kvalita ISO, správa procesů, etc robustní hardware (robustnost, zdvojování) zotavení z chyb latentní chyby ještě se neprojevily, těžko se poznají error masking předstírají, že se nic nestalo (u TCP)
outages odejde všechno řídké, většinou kvůli výpadku napájení pravděpodobnost selhání zahořovací křivka na začátku provozu a před koncem životnosti vyšší na krátkých intervalech bez paměti (poznámky z 1.3. chybí) Modely transakcí spheres of control (první snaha o formalizaci; jakýsi předchůdce transakcí efekty operací se projevovaly ve spheres of control, které uchovávaly výsledky a umožnovaly jejich rušení a daly se i vydělovat a commitovat zvlášť. Zároveň to monitorovalo závislosti mezi operacemi. Koncept se neujal.) flat (ACID) w/ savepoints (dají se dělat savepointy a rollbackovat k nim; savepointy ale nejsou perzistentní, protože by se tím porušovala atomicita tím pádem to neřeší výpadky) chained (chain transaction jako commit+start, ale uchovává se stav výpočtu; commit je persistentní, zůstává kontext, ale můžou se uvolnit zámky; v případě výpadku stejně ztratím stav výpočtu) minibatch (program si průběžně ukládá stav výpočtu) nested strom transakcí parent commit dependent on child (rodič nesmí commitovat dřív než potomek) child abort dependent (když rodič abortuje, musí i děti) rodič nemusí abortovat, když abortuje dítě z ACID porušuje isolation (děti mohou přistupovat k datům změněným rodičem před jeho commitem) a durability (abort rodiče ruší commity potomků) změny dětí se delegují na rodiče zámky: dva druhy: nový v dítěti / předaný od rodiče (dítě vidí zámky rodiče) na konci se rodičovské zámky vracejí rodiči, nové se buď taky předají (commit) nebo zruší (abort) Oracle / MTS: neumí, nově spuštěné transakce jsou nezávislé (transaction suspension/resume) dá se emulovat transakcemi se savepointy (bez paralelního běhu) (při vstupu do dítěte se udělá savepoint, při jeho abortu se udělá rollback do toho savepointu) open nested dlouhé transakce žerou zdroje (zámky se přenášejí na rodiče, neodemykají se) řešení: každý potomek se natvrdo commituje, poznamená se k němu kompenzující transakce, která se s pustí v případě abortu rodiče když někdo sáhne na výsledky mezi commitem a kompenzací: nevadí, mezicommity jsou korektní, jen se to prostě vrátí (účetnictví: když pošlu peníze jinam, tak pak neopravím původní záznam, ale přesunu je zase zpět) kompenzující transakce nesmí abortovat (dá se to udělat) v hierarchických strukturách: když něco přidám a pak to chci kompenzovat smazáním, nechci, aby mi to předtím odmazal někdo jiný může být vyřešeno tím, že vyšší transakce má pořád zamčenou vyšší úroveň záznamů problém: jaké pořadí kompenzací (obvykle v opačném pořadí)
ságy více transakcí, při commitech se ukládají kompenzující transakce, při abortu ságy se postupně kompenzují již commitnuté transakce dlouhé sekvence, co nežerou zámky a přitom jsou atomické (až na problémy s kompenzacemi) split & joint spojování a rozdělování transakcí téměř libovolný graf transakcí split: musí být určeno, které prostředky půjdou komu independent: disjunktní, dohromady dají původní; můžou se commitovat/abortovat nezávisle dependent: něco je sdíleno; vzniká jednostranná závislost (oboustranná = nemá cenu dělit) join: spojení prostředků do jedné transakce použití: hlavní dlouhá transakce s mezivýsledky, které chci zpřístupnit: oddělím mezivýsledky do další transakce, kterou hned commitnu recoverable communication actions zprávy mezi transakcemi závislost odesílatel/příjemce ACTA formální model pro popis transakčních modelů historie: posloupnost akcí transakcí s význačnými operacemi (begin/commit/rollback/...) závislosti mezi transakcemi (hromady) konflikty view set (co transakce vidí: výběr z historie... What data I see ) conflict set (projekce historie... What operations I collide with ) delegace: předávání objektů mezi transakcemi ( What I did but somebody else commits/aborts ) účinky transakce na transakce (závislosti) na objekty (view set, conflict set, delegace) (Pak nějaké šílené formální popisy, které nebudou zkoušeny... 03-SLD-Models od strany 22) Transakční monitory Transakce se dají dělat v odděleném serveru. Když ale máme víc klientů, bude časem potřeba více serverů (kvůli spolehlivosti, škálovatelnosti, etc). Server pool: množina serverů, zpočátku roste s klienty, a když je jich hodně, tak si to nějak rozdělí. Pak je potřeba nějaká fronta a distribuce požadavků mezi servery. Pak se ale musí zajistit konzistence mezi klienty (třeba si na serveru vydržuje nákupní košík pak ale musí pořád sahat na ten samý). To se řeší vydělením tzv. resources dat transakcí jako sdíleného prostředku mimo servery. (Z toho ještě vznikají otázky, co se stane, když část z toho spadne...) Řeší se dvoufázovým modelem commitu (2PC) před commitem se všech účastníků optá, jestli jsou připraveni commitovat. Pak ještě log a zotavovadlo (které kdyžtak zotaví stav podle záznamů v logu).
Servery: ignorant jednoduchý (když neběží transakce, tak si ji spustí) pozorný (dělá savepointy vyžadují propagaci mezi servery) resumable Sessions: vzájemné závislosti mezi akcemi server process per session session se ukládá na klientu sdílejí se v databázi nebo v kontextu Izolace Transakce se nedají izolovat úplně, takže se izolují jen tak, aby pořád dávaly správné výsledky. To se zajišťuje pomocí invariantů. (Př: v obousměrném seznamu musí nekoncové ukazatele být symetrické.) Neatomické operace dočasně invarianty porušují. (Jako u transakcí ty z konzistentních dat musí na konci udělat taky konzistentní, ale konzistence v průběhu se nepožaduje.) Při paralelním běhu by se něco mohlo pokoušet průběžné nekonzistence opravovat, což nechceme. Kvůli tomu je potřeba transakce izolovat. (Korektní paralelní běh dá výsledek, jako by byly vidět pouze konzistentní stavy tj. jako by dal bez paralelismu.) Model transakce: částečně uspořádaná množina atomických čtení a zápisů. Uspořádany jsou jen ty operace, které spolu kolidují. (konfliktní operace: záleží na pořadí, tj. operace na stejných datech, kde alespoň jedna je zápis) Můžou být i konfliktní transakce (obsahují konfliktní operace): u nich také důležité uspořádání. Historie a jejich klasifikace Historie H: obsahuje commitované, abortované i běžící transakce. Commitovaná projekce C(H) obsahuje jen operace commitovaných transakcí. (Konfliktově) Serializovatelné historie ((C)SR): konfliktově ekvivalentní se sériovou historií. Konfliktová ekvivalence: operace, jejichž vzájemné pořadí ovlivní výsledek, jsou ve stejném pořadí. Serializační graf SG(H): šipka T1 --> T2, právě když T1 předchází T2 a T1 a T2 jsou konfliktní. Platí: H je serializovatelná právě když je SG(H) acyklický. H = w1[x] r2[x] w2[y] c2 c1 je serializovatelná. Co když ale T1 chce abortovat? Nemůže, už se projevila na T2. Zotavitelná historie (RC): pokud transakce čte z nějaké data, pak nesmí commitovat dřív než ta, která data poskytla.
Předcházení kaskádovým abortům (ACA): Když jedna píše a několik ostatních po ní čte, při jejím abortu by se muselo abortovat i několik dalších. Řešení: transakce čte data z jiné transakce teprve potom, co tato commitovala. H = w1[x] w2[x] c1 c2 je SR, RC a ACA. Co když T1 abortuje? Když si schovávám verze před zápisem každou transakcí, abort T1 by to vrátil před w1, takže by zrušil i zápis T2. Strict (ST): Nesmím nikam psát, dokud nebyla commitovaná transakce, která tam psala přede mnou. (Klasifikace historií bude typický příklad do písemky.) Prefix commit closed vlastnosti Když platí v historii, bude platit i ve všech jejích prefixech. (Tj. i když nám systém uprostřed spadne, zůstanou v datech platné.) Co když vezmu jiné operace: jen vložení, smazání a čtení unikátní položky. Pak je potřeba znovu definovat konfliktní operace, jinak serializace a podobně zůstává. Pohledová ekvivalence: (Když transakci předhodím stejné vstupy, dá mi stejné výstupy.) Dvě historie jsou pohledově ekvivalentní, pokud platí, že čte-li transakce cizí výsledky v první historii, dělá to i v druhé historii, a pokud jsou v obou historiích stejné finální zápisy. Pohledová serializovatelnost (VSR): H je pohledově serializovatelná, pokud je každý její prefix pohledově ekvivalentní s nějakou sériovou historií. (Bez požadavku na prefixy to sice dá stejné výsledky, ale nebude to prefix commit closed.) Jak serializovat historie? Možné reakce na žádosti o operace: Provést hned Odmítnout Pozdržet Dvě filozofie: Agresivní (snaží se operace vykonat co nejrychleji, nestíhají je přerovnávat, a občas musí operace odmítat) Konzervativní (mají sklony operace zpožďovat, snaží se předejít jejich odmítání) Extrémně konzervativní plánovač: vybere si jednu transakci, ostatní zdržuje, dokud neskončí. Produkuje sériové historie. Značně konzervativní plánovač: vyžádá si od transakcí, kam budou sahat; pouští nekonfliktní transakce. Pro hromady krátkých jednoduchých transakcí je lepší agresivní plánovač; pro složitější transakce je lepší konzervativní plánovač. Zamykání Záleží na granularitě (velká hodně se čeká; malá velká režie na zamykání, vyšší pravděpodobnost deadlocku) Ke standardním operacím (READ, WRITE, COMMIT, ABORT) se přidají zamykací (RLOCK,
RUNLOCK, WLOCK, WUNLOCK). Dobře formovaná transakce: Všechny operace musí být pokryty zámky, zámky jsou korektně spárovány, jsou s nimi prováděny korektní operace (nedá se odemykat odemčený, etc...). Dvoufázová transakce: Když začnu odemykat, už nezamykám. Legální historie: Pořadí zámkových operací je v souladu s tabulkou konfliktů (nemůžu si něco zamknout pro zápis, když už to někdo má zamčené pro čtení). Věty: Když jsou všechny transakce dvoufázové a dobře formované, je každá legální historie serializovatelná. Když transakce poruší jednu z podmínek, dá se udělat další transakce tak, aby vznikl cyklus závislostí. Plánovač: Když přijde požadavek, plánovač ověří, jestli to nekoliduje s nějakým existujícím zámkem. Když ano, tak operaci pozdrží, když ne, udělá si u sebe zámek a pošle operaci k data manageru. Nesmí se odemykat, dřív než data manager potvrdí, že zámkem krytá operace se opravdu vykonala. Jakmile uvolním nějaký zámek, transakce už nesmí zamykat (2PL). (Taky musí řešit deadlocky.) Konzervativní plánovač: od každé transakce chce všechny operace předem a zkusí jí všechno potřebné zamknout. Když to neprojde, transakci odloží. Nedochází k deadlockům. Striktní plánovač: Problém dvoufázovosti: jak zjistit, kdy je možné začít odemykat? Jistotu mám jen na konci. Když budu odemykat až na konci transakce, vzniknou mi striktní rozvrhy. Dá se rozdělit: zámky pro čtení budu uvolňovat, když dostanu pokyn commit/abort; zámky pro zápis, až když data manager ohlásí provedení commitu/abortu. Konflikty zámků: Ty chce / Tx má nic R W R + + - W + - - Izolace / zámky Chyby: Lost update transakce dělá něco s daty r 1 x w 2 x w 1 x... poslední zápis postaven na neaktuální verzi Dirty read w 2 x r 1 x w 2 x... první čte blbou hodnotu (může se stát, třeba když druhá pak abortuje) může způsobovat nekonzistence Unrepeatable read r 1 x w 2 x r 1 x... opakované čtení vrátí jinou hodnotu; až tak moc nevadí Stupně: 0 well formed pro zápis, jinak nic nebude přepisovat dirty data u transakcí s vyšším stupněm (pro read-only transakce bez požadavku na přesné výsledky, nebo low-level opravy dat)
1 dobře formovaná a dvoufázová pro zápis, pro čtení nic bez ztracených updatů (tady je to ale nějaké zamlžené, protože dobře jen tohle ztracený update evidentně umožní podle některých zdrojů to chce, aby zámky trvaly po celou dobu transakce (long-locks). Viz http://nenya.ms.mff.cuni.cz/pipermail/txy/2005-june/000011.html ) (pro r/w transakce, které nepotřebují přesné výsledky... velké statistiky apod.) 2 navíc well formed pro čtení navíc bez špinavého čtení od transakcí se stupněm 1 a vyšším (pro skoro všechny, kde nevadí unrepeatable read) 3 všechno well formed a dvoufázové bez ztracených updatů, špinavého čtení a navíc žádné neopakovatelné čtení od transakcí st. 1+ Transakce na stupni 0 nemůžou rollbackovat. V SQL 2: read uncommited možné špinavé čtení, neopakovatelné čtení, i phantom read cosi jako 1 read commited znemožňuje špinavé čtení v podstatě 2 s cursor stability (když máte někde kurzor, tak vám vydrží) repeatable read v podstatě stupeň 3, ale neřeší problém fantomů serializable všechno Read past locking: přeskakuji položky zamčené pro zápis (dobré pro statistiky). Fantomy Když vybírám a nic nenajdu, co mám zamknout? Prázdný výsledek mi tvrdí, že tam nic není. Aby mi tohle vydrželo, musel bych zamknout celou databázi. Když vymažu všechny zelené položky, co se má zamknout? Pak se třeba spoléhám na to, že v databázi nic zeleného není. Řešení: Pamatuji si zámky pro predikáty, zámky budou konfliktní, pokud se predikáty nevylučují. Nedá se lehce určit, jestli jsou predikáty konfliktní. (NP-úplný problém) Pamatuji si predikáty, pro které by se mělo zamykat. Při každé úpravě databáze porovnávám s predikáty v paměti, když něco uspěje, čekám. Problémy: rychlost, šance na deadlock. Zámky na indexech zamknu si rozsah hodnot, na který mi pak nikdo nemá sahat. Zamykám jednotlivé položky indexu, které se vztahují k intervalům hodnot. Tím se dá předcházet nevhodnému vkládání. Podrobnosti viz slidy. Hierarchické zamykání Co když chci mít transakce pracující na různých úrovních hierarchie? (Mám zamčeno několik buněk, ale jiná transakce chce přepsat tabulku jako celek?) Intention lock zvláštní druh zámku, říkající, že transakce má v úmyslu zamknout něco na nižší
úrovni. (Problém: intent koliduje se čtením, občas zamyká až moc.) Intention read + intention write: Před zamknutím zamknu na intention od kořene (pak uvolňuji zdola nahoru) chci / zamknuto nic intent share intent exclusive share share intent exclusive intent share + + + * + + - intent exclusive + + * + * - - - share + + - + - - share intent exclusive ** + + - - - - exclusive + - - - - - * nevadí, zapisovat do jiných potomků můžu, případný konflikt se najde na nižší úrovni ** jedna transakce má současně share a intent exclusive (viz kombinace zámků) exclusive Problém: update nejdřív zamkne pro čtení, pak povýší na zápis. Když se spustí dva zároveň, vznikne deadlock. Řešení: Update zámek. (zamykám pro čtení, ale brzo budu chtít psát) (snese se jen se čtením, psaní a update nejde... občas se při existujícím update zámku odmítá čtení, aby se na něj pak nemuselo čekat) Když mám víc hierarchií (indexy, acyklický graf): Před čtením zamknu alespoň jednoho předka pro intention read Pro současné čtení asi nevadí, protože s prvky indexu se stejně nemanipuluje, sahá se jen na listy. Před zápisem zamknu všechny předky pro intention write Když chce jedna transakce další zámky: Konverze zámků vs. víc zámků Zamykání nested transakcí Když běží sekvenčně, stačí udržovat zámky v LIFO (vracet od konce) Při paralelním běhu se zámky dědí a vrací rodiči (při commitu) (nové se při abortu pouští) Granularita zámků Na každou se dá najít pomalý případ Dá se měnit za běhu (když má moc zamčených řádků, může se to převést na celou tabulku) (nebo naopak začínat s hrubými, a při čekání je zjemňovat to ale jde špatně, protože potřebuji další informace, proč byla vyšší entita zamčena) Deadlocky Timeout (Těžké najít vhodnou dobu, zbytečné zabíjení dlouhých transakcí. Ty se obykle systém pokusí spustit znovu, což může vést k zahlcení a neustálém abortování všeho.) Wait-for-graph Dají se doplňovat hrany podle pořádí čekání (rychlejší detekce) Speciální vlastnosti: graf je řídký (když se hodně čeká, systém stejně za nic nestojí), cykly jsou krátké Řešení deadlocku: Dá se abortovat libovolná transakce v cyklu
Například ta s nejkratším transakčním logem Distribuované systémy: Centrální řešení (problém: informace mohou být staré phantom deadlocky) Path pushing (když na něco čekám, pošlu mu o tom zprávu (co přijde, forwarduji); když se dozvím, že čekám sám na sebe, našel jsem deadlock; problémy: možné phantom deadlocky, zpoždění při posílání, nutná homogenita) Prevence: Podle priority: čekání jen vyšších na nižší (nebezpečí opakovaného zabíjení livelock, dá se zamezit spuštění s vyšší prioritou) Podle timestampu: stáří místo priority (prevence livelocku) B má čekat na A: Wait-die (B>A... B čeká; B<A... B abort) Wound-wait (B>A... A abort; B<A... B čeká) V transakčním systému by se nemělo moc čekat... deadlocky by měly být ještě řidší (jsou řidší^2). Dlouhé transakce jsou problém... (sdílené) zámky mají smysl Velký počet transakcí je problém... transakční monitor má smysl Dá še řešit zámky v OS (při paralelním běhu plánovače), nebo normálními proměnnými, když bude plánovač v jednom vláknu. Použití hašů v tabulce zámků je možné ignorovat kolize (z hlediska izolovanosti nevadí, ale může způsobovat zbytečné čekání a deadlocky tohle se stává i když zamykám vyšší entity... třeba stránky) Co když transakce spadne? Zámky kryjí nekonzistentní stavy nedá se prostě odemknout U dat v paměti těžko řešitelné Salvaging procedures zkontrolují, jestli jsou v paměti smysluplná data, a případně je opraví jen málokdy Konvoje Hot spot resource: všichni na ně chtějí sahat (log, konzole, konto Oskara...) pořád zamčené Vznikají úzká místa: transakce se seřadí ve frontě u hotspotu a pak už jsou v podstatě sériové Čekání z lock-unlock na lock-reschedule-reschedule-unlock (může se přeplánovat na jiné, které ale stejně čekají na hotspot, tj. zbytečně)... dá se zabránit zákazem přeplánování transakcí, co mají zamčený hotspot Timestamp scheduling Nepoužívá zámky; konfliktní operace se vykonají v pořadí timestampu transakcí. Získání TS: (počítadlo, hodiny, v distribuovaném prostředí dvojice <počítadlo, TM_id>) Plánovač přijímá operace a kontroluje, jestli splňuje TS ordering pravidlo, když ho porušuje, transakci abortuje. Je potřeba pamatovat si maximální pro každou dvojici [operace, položka] Plánovač dostane operaci p_i[x] transakce T_i: porovnáme ts(t_i) s max-q-scheduled[x] pro každé q, které je v konfliktu s p_i[x]. Pokud je ts(t_i) < max-q-scheduled[x], odmítneme p_i[x] Jinak p_i[x] naplánujeme a zvýšíme max-p-scheduled[x] na ts(t_i)
Plánovač by měl garantovat, že data manager operace neproházel. (Měl by čekat na potvrzení konfliktních operací.) (Dvoufázové zamykání tohle řeší, protože se další operace nemůže naplánovat kvůli zámkům) Vedou se záznamy o zpracovávaných operacích pro každý prvek; operace se pošle, až když nejsou ve zpracování žádné operace s ní konfliktní. Jinak se zařadí do fronty (kde jsou operace seřazené podle TS plánovač zdržuje transakce). Vznikají serializovatelné, ale nutně ne zotavitelné historie. Zotavitelnosti se dá dosáhnout tím, že nečtu necommitovaná data (čtu jen ty položky, kde w-in-transit je 0, a ten se nebude nulovat při zápisu, ale až při jeho commitu). (To se sice začíná podobat dvoufázovému zamykání, ale pořád to není to samé, protože TS může vygenerovat historie, které 2PL nemůže.) Jak zabránit zbytečným abortům konzervativnější plánování, čekání na staré transakce. Serializační graf Plánovač přijímá operace a staví podle nich obdobu serializačního grafu, odmítá operace, které v něm vytvoří cykly. (Všechno buď hned naplánuje, nebo zabije agresivní plánovač.) Stored SG... omezená varianta, nejsou v něm staré commitované transakce, ale zase tam jsou nové, ještě neukončené. (Můžu odstranit staré transakce, které jsou commitované, a do kterých nic nevede nemůžou být součástí cyklu.) SGT (Serial Graph Testing) produkuje serializovatelné, ale ne striktní historie (na to je také potřeba něco jako write-in-transit). Certifikátory Všechno okamžitě provádí, až při commitu ověřuje, jestli jsou operace korektní, a podle toho ho (ne)povolí. Také řeší, jak zjišťovat korektnost: principy 2PL, TO, SGT. Kvůli zotavitelnosti se při abortu abortují i všechny transakce, které po ní četly. 2PL certifikátor: nebere v úvahu pořadí transakcí, takže někdy abortuje, i když by 2PL prošlo. TO certifikace: stejné jako TO, ale nechává chybné transakce zbytečně dobíhat do konce. Mají vůbec certifikátory smysl? Malý počet kolizí Distribuovanost (normální plánovače vyžadují průběžnou komunikaci a mohou být neefektivní, certifikátory ověřují až na úplném konci 2PL a TO certifikátory mohou rozhodovat distribuovaně pomocí dvoufázového commitu (2PC)) Integrovaný plánovač Řeší zvlášť konflikty čtení a zápisů, pak výsledky kombinuje. Thomas Write Rule mám w_1(x) w_3(x), pak přijde w_2(x) Normálně bych ho kvůli čtení muset odmítnout. Když mě ale čtení nezajímá, dá se brát, že už to w_3 (x) stejně přepsalo, takže w_2(x) můžu a zahodit a transakci tvrdit, že jsem ho provedl. TO/TWR pro RW konflikty používá TO, pro WW konflikty TWR. Obojí používá stejné timestampy, takže se bez problémů dohodnou. 2PL/TWR pro RW konflikty používá 2PL, pro WW konflikty TWR. K zaručení společné funkčnosti stačí zajistit, že pořadí commitu bude souhlasit s uspořádáním časových razítek. To se
dělá tak, že se timestampy přidělují až při commitu (tj. kolize zápisů se testují až na konci). Verzování Zápis nepřepisuje stará data, ale vytváří nové verze dat. (Ty se často ukládají tak jako tak. Např. pro účely zotavení nebo auditu.) Psaní tedy nikdy nekoliduje, u čtení se pak doplňuje, jaká verze se čte. Existence verzí pomáhá zvládat plánování opožděných operací. Pravidla Čtu jen ty verze, které už někdo (starší) zapsal Když chci přečíst, tak přednostně čtu svoji zapsanou verzi Když čtu necommitovaná data, nemohu commitovat dřív než ten, kdo ta data uložil (zotavitelnost) (Je to přímo v definici, protože commitovaná projekce historie by nebyla úplná zbyly by v ní transakce, co četly neexistující verze.) Konfiktová ekvivalence pro multiversion history nestačí (vlastně tam žádné konflikty nejsou). Je tedy potřeba pohledová ekvivalence. Pohledová ekvivalence pro singleversion stejné read-from vazby mezi transakcemi stejný poslední zápis Pohledová ekvivalence pro multiversion read-from vztah není daný pořadím spouštění, ale explicitně ve čtecích operacích všechny zápisy v MV historii jsou (svým způsobem) finální tj. dvě MV historie jsou pohledově ekvivalentní, pokud mají stejné operace Serializovatelnost sériová MV (SMV) historie transakce jdou za sebou (triviálně) nestačí pro rozumné výsledky, transakce můžou číst staré výsledky, když chtějí některé MV sériové historie nejdou vůbec převést na jednoverzové one copy serial historie (1SMV)... SMV historie pohledově ekvivalentní s nějakou sériovou jednoverzovou historií. one serializable history (1SR) je historie, jejíž commitovaná projekce je ekvivaletní s nějakou 1SMV historií Serializační graf hrany T2->T1: T1 čte hodnotu zapsanou T2 (ukazuje pohledovou ekvivalenci, ale ještě moc neřeší serializovatelnost) konverze MV na 1V může změnit reads-from vlastnost => => přidáme hranu z T1 do T2, pokud T2 zapsala po T1 a ještě nakonec to něco přečetlo => přidáme hranu z T1 do T2, pokud T1 četla hodnotu, kterou pak T2 přepsala (pro kterou zapsala novější verzi) MV historie je 1SR právě když MVSG je acyklický Multiversion timestamp ordering Musí ke všem operacím doplnit čísla verzí (transakce samotné o nich nevědí) Čtení čte poslední zapsanou verzi dostupnou v okamžiku plánování Pro každou položku je třeba pamatovat si, kdo naposledy četl, aby se dalo předcházet situacím, kdy přijde dodatečná nová verze položky, se kterou už (formálně starší) transakce pracuje.
Multiversion two phase locking (MV2PL) neschovává staré verze a mnoho necommitovaných verzí neplýtvá místem čtecí a zapisovací zámek (zapisovací brání vytvoření nové verze, čtení zapisované verze) certifikační zámek kvůli čekání na dočtení starých verzí po commitu verze nové (read lock koliduje s certifikačním, write lock koliduje s write a certifikačním zámkem, certifiační koliduje se vším; před commitem se přehodí zapisovací zámek na certifikační, což způsobí čekání na dočtení staré verze) čte jen commitovaná data (předchází kaskádovým abortům) může způsobit deadlock Smíšené rozdělení transakcí na query (jen čte) a update (čte i zapisuje), jsou plánovány odděleně updaty: pomocí striktního 2PL, v okamžiku commitu dostanou timestamp query: dostanou timestamp menší (starší) než všechny aktivní updaty. Všechna čtení vidí verze s nejbližsím starším timestampem. Díky staršímu TS čtení nikdy nečeká a nemůže abortovat Místo timestampů si může každý čtenář udržovat commit list seznam transakcí, které commitovaly a ze kterých může číst. Commit Musí být atomický více částí transakčního systému se musí shodnout na tom, co se stalo. Podobné distribuovanému konsensu. Obecně nejde (při libovolných selháních), dá se omezit na rozumné podmínky: časový limit na doručení zpráv uzel se po selhání časem zotaví při selhání uzel nebude šířit chaos v okolí Dvoufázový commit přípravná fáze koordinátor pošle všem zprávu prepare účastníci závazně odpoví prepared nebo not prepared commit když jsou všichni připraveni, koordinátor přikáže commit, jinak abort Po odeslání prvního potvrzení koordinátorem může transakce skončit už jedině commitem Když po odsouhlasení commitu nějaký uzel selže, musí si to po zotavení pamatovat a všechno dokončit. Součástí je i recovery protocol a termination protokol pro řešení problémů. Recovery protokol pro koordinátora koukni se do logu a zjisti, kdy jsi skončil Recovery protokol pro účastníka Mezi ohlášením schopnosti commitovat a commitem sám o sobě neví, jak má transakce dopadnout, a při zotavení se na to musí optat koordinátora.
Zefektivnění Jednoúrovňový strom (doteď)» Commit trvá 3 kroky (krok = rozeslání všech zpráv, které mohly být odeslány) Lineární / kruh» Někdo začne, pošle prepare/commit» Další se k tomu může přidat, pošle dál. Když už zpráva má potvrzení všech účastníků, postupně se commituje.» Když někdo chce abortovat, rozešle abort (třeba i na obě strany)» Pomalejší commit trvá 3N kroků All-to-all (broadcast)» Nejdřív se broadcastem pošle prepare.» Pak každý broadcastem odpoví stav a všichni vědí všechno.» 2 kroky, pošle se víc zpráv. Strom» Může kopírovat topologii sítě (účastníci procesy, můžou běžet na různých strojích)» Rozdělím účastníky podle toho, kde jsou.» Koordinátor posílá prepare jednomu účastníkovi na daném uzlu. Ten se stane lokálním koordinátorem uzlu, dohodne to s ostatními, a nahoru pošle už jen výsledek. Optimalizace Umožní se posílat potvrzení ještě před výzvou Účastník, který u sebe v průběhu transakce nic neměnil, může na prepare odpovědět zprávou read-only, kterou umožní koordinátorovi, aby ho vyhodil z logu a commit fáze a ušetřil si práci. Problémy Když účastník transakce čeká na potvrzení koordinátora, nemůže sám dělat nic. V této době uzly v praxi často odmítají požadavky na změny (aby je mezitím paralelní požadavky nerozbily). To může způsobit problémy, když nějaké uzly potřebují komunikovat s ostatními účastníky, kteří už můžou být zablokování po prepare. To se řeší posíláním pre-prepare zprávy, po které si uzly vyprázdní buffery apod. Blokování... řeší se třífázovým commitem.
Concurrency set: jaké stavy mohou zároveň nastat. Třífázový commit (Teoretická záležitost, kvůli malé pravděpodobnosti selhání nemá cenu implementovat.) 1. Send prepare 2. Wait for yes 3. Send pre-commit (už se ví, že se bude commitovat) 4. Wait for ack 5. Send commit Když je účastník v nerozhodnutém stavu, ví, že nikdo jiný ještě necommitoval. Uzel může na vlastní pěst rozhodnout, co dělat v nejisté periodě. Doplnění funguje ale pouze v případě, že v jednu chvíli selže nejvýše jeden uzel. Když umře koordinátor, dá se konec transakce poznast z toho, jak dopadl kterýkoli jiný uzel. Dá se vyrovnat i se selháním sítě, to ale přináší problém při rozdělení sítě vzniknou dvě nezávislé skupiny. (Pak se to řeší tím, že pouze skupina, která má nadpoloviční počet uzlů, může pokračovat. Tímse algoritmus stane opět blokujícím.) Další řešení blokování 2PC: heuristická rozhodnutí Když by účastník měl čekat, rozhodne se na vlastní pěst. (To může vést k nekonzistenci, ale někdy je to levnější než se zdržovat; a pak se to stejně dá později opravit podle logu.) Log manager Jen píše, co mu ostatní říkají. Možné problémy s bezpečnostní (promíchávání různých záznamů s různou důvěrností).
Píšou se do něj undo/redo záznamy účastníků transakcí (pro necommitované a zapsané věci undo, pro commitované a nezapsané redo). Musí se brát ohled na cache. (Flush = spláchnutí; Pin x = pokyn nechávat záznamy v cache; Unpin x = zrušení pinu) Cache strategie s undo i s redo slide 16/3 Vedu si seznamy aktivních/commitovaných/abortovaných transakcí. Zápisy se kromě posílání do psací cache píšou do logu. (Zápisy natvrdo se neprovozují, tohle si řeší cache sama.) Při commitu se transakce označí za comitovanou a neaktivní; při abortu se podle logu obnoví staré hodnoty (přidá je do psací cache) a transakce se přehodí do abort listu. Po pádu se zruší cache, a pak se prochází dozadu log a pro každou hodnotu se kouká, jestli to není později nepřepsaný zápis commitované transakce. Pokud ano, tak se pošle k zápisu. Strategie bez redo Každý commit se musí spláchnout. Při zotavení stejně musím procházet log, abych odmazal necommitované zápisy. Strategie bez undo Při zápisu se cache přikáže, aby to nepsala na disk (pinem), na psaní se to pošle až při commitu (třeba unpinem). (Ale až po přidání do commit listu.) Při zotavení nemusím řešit undo, protože na disku mám jen commitované zápisy. Strategie beze všeho Psalo by se jen do cache s ponecháním v paměti. Při commitu by se musely všechny zápisy atomicky spláchnout současně s označení transakce jako commitované. Jsou potřeba atomické zápisy na disk, asi i s udržováním nějaké dynamické struktury, kde jen (atomicky) měním ukazatele na aktuální verze. Atomické zápisy logu Sériové zápisy: nechávám dvě kopie, vždy zapíšu první, po flushi druhý. Při čtení koukám na první a je-li poškozen, na druhý. (Pomalé.) Časová razítka: mám dvě kopie, vždy píšu přes starší. Při čtení se podívám, která je novější, a tu vezmu. (Rychlejší, čte se málokdy.) Zdržené zápisy: Hromadím zápisy, dokud jich nebude dost, pak je zapíšu najednou. (Může vést k deadlocku, protože transakce můžou na úspěšný zápis čekat.) V praxi: mám dva kusy, na konec píšu volně, když se nahromadí nových zápisů dost, označím je pomocí log anchor, a tím je jasné, že jsou spolehlivě zapsány. Low water mark: nejstarší zápis, resource usage (necommitované psané), restart transakce (minimum z obou), archivní water mark (první nezálohované resource usage). Záznamy pod restart low water mark mohou být bezpečně archivovány; záznamy pod archive low water mark mohou být zahozeny. Problém s příliš starými water marky (při dlouhých transakcích; blokují archivaci) řeší se odsunutím do zvláštního logu nebo přesunutím dopředu. Správa front, etc Řízení zátěže transakčního systému rozložení peaků. Spolehlivé hromadění výsledků (když uživatel odejde, výsledek se pak nezahodí, ale čeká na něj) Zotavení datových vstupů (při selhání se zachovají vstupy).
Existují jakési dlouhé vzorce pro výpočet doby zpracování požadavku ve frontě při nízkém množství vláken hodně, pak to klesá k optimu a pozvolna roste. Thrashing přetížení požadavky způsobí zahlcení, pak pracuje pomaleji, než kdyby bylo požadavků méně. Nešťastný load balancing mezi více počítači může vést k přehazování úloh na jiný počítač, který musí ještě číst z disku jiného uzlu, a to způsobí celkové zpomalení. Problém s autentizací: serverové procesy běží s vyššími právy, než reálný uživatel, takže se s požadavky musí nést informace o tom, kdo je chce. CORBA Standard pro komunikaci mezi procesy v distribuovaném prostředí. Uzly exportují objekty, jejichž metody mohou ostatní volat pomocí náhradních (proxy) objektů. Ty pak jen pošlou pryč požadavek a vrátí došlý výsledek. IDL jazyk pro popis rozhraní, nezávislý na jazyku konkrétní implementace, vypadá jako divné C++ (sekvence = posloupnost parametrů stejného typu, any = jakýkoliv typ) OTS Object Transaction Service Zajišťuje transakce zavolá se, kouká, co se děje, a pak koordinuje commit/abort. Transactional Client vyvolává operace na transakčních objektech Transactional Object objekt, který je ovlivněn transakcí Recoverable Object transactional object, který se účastní commitu/abortu Resource Object zástupce recoverable objectu pro účely komunikace s OTS (některé databáze taky umožňují exportovat příslušné interfacy) struktury: enum status enum vote TransIdentity každá transakce má koordinátora a id (otid_t) PropagationContext kontext transakce? Různé výjimky (TRANSACTION_REQUIRED, TRANSACTION_ROLLEDBACK, INVALID_TRANSACTION,...)
interface Current mají ho klienti i servery váže transakci s vláknem metody begin, commit, rollback rollback_only: můžou ho vypustit servery, když potřebují zrušit transakci, aniž by něco zkazily okamžitým rollbackem Control object vrátí reprezentaci aktuální transakce Status vrátí status transakce Suspend suspenduje transakci, vrátí control objekt, který ji může opět svázat s aktuálním vláknem pomocí resume interface TransactionFactory je taky všude má metodu create na vytvoření nové transakce Context Propagation implicitní (begin se volá přes Current, vše ve vláknu je pak v transakci) explicitní (vyrobím si transakci přes TransactionFactory, pak volání asociuji o objektem Control, který transakci reprezentuje) Control object má dva interfacy Terminator: jednoduchý, umí jen commit/rollback Coordinator: umí toho víc (optat se na stav, na rodiče je li vnořená a tak podobně) Resource interface Metody pro ovládání commitu/rollbacku Když se objekt zapojí do transakce, registruje svůj resource v jejím Coordinatoru Může se registrovat i synchronizační interface, aby byl varován před dvoufázovým commitem I nějaká registrace pro vnořené transakce RecoveryCoordinator Zajišťuje obnovení v případě pádu Serveru stačí pamatovat si jeho referenci Resource používáný při dvoufázovém commitu má metody prepare (vrací Vote: commit/rollback/read only), potom rollback a commit. (vše volá transakční služba) commit_one_phase volá se, když je jen jeden objekt, a není tedy potřeba dvoufázový commit forget objekt si pamatuje heuristická rozhodnutí, tímhle se říká, že je už může zapomenout další interfacy na resourcech Synchronization pro události před a po skončení transakce SubstransactionAwareResource pro reakce na subtransakce (bez dvoufázového commitu) TransactionalObject jen značkovalo objekty, které měly dostávat informace o transakcích, v dalších verzích se to řeší politikami TSIdentification identifikace transakční služby Sender/Receiver balí do RPC CORBY transakční informace OTS Asynchronní zprávy Sychronní se zpracovávají ve stejné transakci stejné jako volání metody
Store & forward asychronní: doručují se po commitu, zpracovávají se v jiné transakci Concurrency Control Service Samotná transakční služba neřeší zámky Terminologie Lock Set zámek (objekt asociovaný s daty, dá se zamykat v různých režimech) Lock lock mode (způsob zamčení) Zámky: read, write, upgrade, intention read, intention write U každého zámku je Lock Coordinator, který ho umí najednou zrušit/odemknout Kromě LockSet je ještě TransactionalLockSet, kterému se i explicitně předává transakce LockSetFactory je továrna na zámky Java Transaction API Nějaká rozhraní, objekty, etc... UserTransaction rozhraní pro aplikaci rozhraní pro aplikační server (v něm běží aplikace)... pro svazování resourců s transakcemi jeden resource může být v nejvýše jedné transakci najednou (dá se suspend/resume) synchronizační rozhraní (dá se registrovat u transakce, volá se před ukončením a po něm) XAResource resource manager má metody pro registraci a odregistraci v transakci (volá transaction manager); prepare, commit, rollback a forget pro dvoufázový commit globální transakce zahrnuje víc resource managerů lokální transakce nad jedním resource managerem Transakce je vždycky vázaná na thread, který ji spustil. Jako transaction manager je používá OTS. Java Beans komponenty zalepené v nějakých kontejnerech, které poskytují různé služby (transakce) volají je jsp servlety z webserveru dva druhy interfaců (home dělá nové komponenty, remote vlastní funkce beanu, local to samé, ale s předáním argumentů odkazem) Druhy beanů session reprezentují spojení, mohou být stavové a reagovat na transakce entity objektový pohled na externí data (dají se mapovat do tabulek databáze) stavové message driven spouští se přijetím jedné zprávy jsou bezestavové, mohou reagovat na transakce Kontejner Poskytuje lifecycle management beanů perzintenci beanů
transakce Potřebuje seznamy typů beanů... Deployment descriptor popisuje vztahy a závislosti, stavovost, kdo spravuje transakce, etc Beany můžou mít vztah k transakcím NotSupported (když je, tak se suspenduje) Required (když není, udělá se nová) Supports RequiresNew (vždycky nová, původní se kdyžtak suspenduje) Mandatory (když není, padne to) Never (když je, padne to) (zbytek chybí) Další praktické příklady CORBA Activity Service dlouho běžící transakce nemusí být atomické (jednotlivé kusy se nemusí shodnout na úspěšnosti) Aktivita může (a nemusí) obsahovat další aktivity a transakce má stav (běžící/ukončená s nějakým výsledkem) Účastníci si posílají signály přes tzv. Signal set. (Těch může být více, např. specializovaný pro dvoufázový commit.) Action interface interfacy u účastníků, přes které komunikují. Když aplikace chce commitovat, zaregistruje si svoje Action interfacy, vybere si nějaký signal set, který umí dvoufázový commit. Když aplikace něco chce dělat, řekne to Activity service, ta se zeptá Signal setu na signál, pak ho rozešle účastníkům, posbírá odpovědi a vrátí je Signal setu. rozhraní SignalSet (??) Action (jediná podstatná metoda je ProcessSignal) ActivityCoordinator (metody complete_activity, process_signal_set, registrace signal set, etc) Current pro jednoduché věci Business Transaction Protocol víceméně dělá to samé co CORBA Activity Service definuje jen zprávy, neřeší interfacy Business Transaction koordinovaná aktivita stav: Provisional Effect, pak (Final Counter) Effect
někteří účastníci mohou mít Final a jiní Counter Actors účastníci business transakce superior koordinátoři; inferior podřízení (jdou z toho stavět stromy) superior mohou vyžadovat atomicitu (atoms; podřízení musí skončit na Confirm nebo Cancel) nebo dovolit různé výsledky (cohesion composers; výsledky podřízených závisí na aplikaci) zprávy všechny definovány na abstraktní úrovni BEGIN / BEGUN zahájení business transakce CONTEXT obsahuje informace, přibaluje se k ostatními ENROL / ENROLLED registrace u superiora RESIGN / RESIGNED odregistrace PREPARE / PREPARED CONFIRM / CONFIRMED CANCEL / CANCELLED ^ dvoufázový commit CONTRADICTION, HAZARD když se něco v transakci zvrtne X/Open Distributed Transaction Processing starší je jasné, že funguje :-) zavedl rozdělení na aplikaci, transakčního koordinátora a resourcy interfacy TX mezi aplikací a manažerem tx_(begin commit rollback) XA mezi resourcy a managerem má ho každá dnešní rozumná databáze umí ho každý rozumný transakční manažer xa_(prepare commit rollback) pro dvoufázový commit, etc Zkouška co bude chtít písemka cca 90min, vybírá se z balíku veřejných otázek úvod: vysvětlit ACID u flat transakcí spolehlivost: MTTF, MTTR, dostupnost modely: k čemu jsou, vlastnosti, rozdíly (z ACTA nanejvýš co to je dependency, určitě ne jednotlivé kusy) serializace: umět zformulovat a definovat serializovatelnost, ekvivalenci, apod. (napište historii, která...) plánovače: agresivní/konzervativní, jak fungují, zámky (well formed, legální,...), dvoufázový plánovač izolace: stupně, co zaručují, fantomy a jak se jich zbavit, hierarchické a intention zámky, update zámky, deadlocky (vzorce určitě ne) timestampy: jak se to dělá, implementace (co si pamatovat) serializační grafy, certifikátory integrované plánovače: k čemu, Thomas write rule, kombinovaný plánovač multiversion historie (určitě ne commit list) dvoufázový commit, jeho optimalizace, třífázový commit (jako těžší věc) log manager: strategie s undo/redo praktické systémy: principy (co všechno je na rozhraní účastníka?), XA interface, určitě nebudou seznamy výjimek apod.