Modely a vlastnosti transakcí

{{multiple image

|align = tright |direction = horizontal

| image1 = Transakce.png

| width1 = 416 | caption1 = Transakce notace podle Graye

| image2 = Flat.png

| width2 = 400 | caption2 = Flat model(př.3 stavy): transakce T je aktivní (a bude ABORTovat), T je ABORTovaná, T je COMMITovaná

}} Transakce je posloupnost akci (r, w, vypocet,..) nad persistentními daty se kterou se zachazi jako s celkem.

Zacatek transakce se oznacuje obvykle BEGIN, konec COMMIT/ABORT,ROLLBACK. V pripade neuspesneho zakonceni transakce se system vrati do stavu pred zapocetim te transakce.

Databázové transakce musí splňovat tzv. vlastnosti ACID (viz [[wen :: ACID]]):

:Atomicity - Transakce proběhne celá, nebo vůbec. :Consistency - Při provádění transakcí se DB převádí z jednoho konzistentního stavu do jiného.

:Isolation - Transakce o sobe navzájem nevědí, jako by běžela jen jedna. :Durability - Změny commitnuté transakce jsou trvalé.

Flat Model (FM)

Omezení transakčního modelu flat transactions, která mohou bránit jeho praktickému využití v některých transakčních systémech:

*Mají příliš velký rozsah. Abortu po stotisící operaci se nedá nijak zabránit. To se dá přičíst tomu, že nemají žádnou vnitřní strukturu. *Žádný dílčí neúspěch není tolerován. Pokud je špatně jediné číslo konta u deseti tisíc zaměstnanců nějakého podniku, pak transakce odeslání mezd všem zaměstnancům kvůli této chybě abortuje.

*Flat transakce nemohou spolupracovat s jinými transakcemi. Nemohou s nimi sdílet data (pro sdílení dat neexistují žádná primitiva nebo pravidla), nemohou být vzájemně propojeny přes signifikantní události. *Neřeší přirozený problém vnoření do sebe. Běžné programovací jazyky umožňují vnořovat volání procedur, take se může stát, že zavoláme v transakci proceduru, která zahájí novou vnořenou transakci.

{{multiple image

|align = tright |direction = horizontal

| image1 = Sp.png

| width1 = 357 | caption1 = SavePointy

| image2 = CT.png

| width2 = 420 | caption2 = Zřetězené transakce

}}

Savepointy (SP)

*podporuje MS SQL Server 2008 a Oracle také commitovány. *rollbacky se neprovadi az na zacatek, ale k jiz ulozenym savepointum (první SP většinou po startu transakce).

*dopředný rollback **rollback k rollbacknutým stavům

**rollbacky se pak stávají součástí historie *neřeší tvrdé výpadky systemu ⇒ po opetovnem nabehnuti systemu se musi transakce provest znovu, ne od posledniho savepointu, persistetní savepointy zase nemusí odpovídat stavu kódu transakce

{{collapse|Dopředný rollback detailně| Dopředný rollback u SP si představuju jako akci zpět a dopředu u prohlížečů.

Akce zpět způsobí klasický rollback k danému SP (tj. v prohlížeči se vrátit o X stránek zpět).

Akce dopředu způsobí, že se zruší rollback a vrátíš se k původně smazanému SP (tj. v prohlížeči jít o X stránek dopředu).

V praxi si myslím, že to funguje následovně (předpoklad: těsně před zavolání rollbacku se vytvoří SP):

SP1 ... SP2 ... SP3 ... SP4 ... SP5 + Rollback(SP2)                    ... SP6 ... Rollback(SP5)

Vyzvětlivky:

• Rollback(SP2) způsobí vytvoření SP5 a zrušení efektu akcí mezi SP2 a SP5;

• Rollback(SP5) funguje jako dopředný rollback - tj. smaže se efekt akcí mezi SP2 a SP6 a znovu se projeví efekt akcí mezi SP2 a SP5.

Ale tadyto jsem nikde nevyčetl, je to spíš moje představa o tom, jak by to mohlo fungovat.}}

Zřetězené transakce (Chained Transactions - CT)

*Programátor se po části výpočtu vzdá možnosti rollbacku nad touto částí, tj. komituje

*Nechce ale ztratit kontext, kurzory, atp. *Tj. je potřeba zavést atomickou operaci Chain work = Commit + Begin

Soubor:nt.png

Hnízděné transakce (Nested Transactions - NT)

výpočet jako hierarchie transakcí, zobecnění SP

Pravidla pro podtransakce:

*COMMIT pravidlo - po potvrzení podtransakce jsou výsledky dostupné jen v rodičovské transakci, podtran. skutečně potvrdí až s potvrzením kořenové transakce *ROLLBACK pravidlo - pokud je podtransakce zrušena, bere sebou všechny své potomky (i když už lokálně potvrdili), když je zrušena kořenová transakce

*pravidlo viditelnosti změn - zmeny v podtransakci jsou po lokálním COMMITu vidět jen v rodiči, objekty držené rodičem jsou přístupné potomkům, potomci jsou izolovaní v případě souběžného spuštění *rodič rozhoduje o řešení zrušení potomka (restartovat, zvolit alternativní výpočet, abortovat)

ACID vlastnosti podtransakci jsou splnene jen částečně: A - podtr. jsou A jen z rodiče, C - podtr. jsou C vzhledem lok.fci., I - silná, D - neplatí kvuli commit pravidlu

Distribuované Transakce - DT (🎓)

|

Zamykaní v DT - centralizované/decentralizované

|wedding.png does not exist. Create it?{: alt="wedding.png"}|

Dvoufázový Commit 2PC (two-phase commit)

Izolace transakcí, alokace prostředků. Uzamykací protokoly, časová razítka. (🎓🎓)

Rozvrhy (VSR ⊃ CSR a RC ⊃ ACA ⊃ ST)

Izolace transakcí

Zámky

Uzamykací protokoly

::

::

::

Deadlock (uváznutí)

Časová razítka - Time Ordering (TO)

::

::

Pomocí precedenčního grafu (PG)

Certifikace (optimistické řešení)

Multiversion data

::

Zotavení z chyb, žurnály (🎓🎓)

ARIES (Algorithms for Recovery and Isolation Exploiting Semantics)

::