Transakční zpracování

Transakční zpracování

[[Transakce.pdf]]

ACID

1. Popis ACID vlastností:
   • Atomicity (Atomicita): Transakce je buď zcela provedena, nebo vůbec neprovedena.
     • Buď všechno, nebo nic
     • Pomocí nějakého logovacího systému, dokáže systém číst historii
   • Consistency (Konzistence): Transakce převádí databázi z jednoho konzistentního stavu do jiného konzistentního stavu.
     • Dodržuje pravidla
     • Například, pro bankovní databázi nedovolíme záporný zůstatek
   • Isolation (Izolace): Transakce probíhají nezávisle na sobě.
     • Stará se o to rozvrh, více v #Vlastnosti rozvrhů
   • Durability (Trvalost): Jakmile je transakce potvrzena, její výsledek je trvalý i při výpadku systému.
     • Řešení je například duplikovat na jinou databázi

Vlastnosti rozvrhů

Stav databáze se mění během vícevlákonové exekuce, kde vlákno dává přístup k datům pro jiné vlákno?
-> porušuje Izolaci a konzistenci

Rozvrh poskytuje :

Uspořádatelnost (Serializability):

Definice: Rozvrh je uspořádatelný, pokud jeho výsledky odpovídají nějakému serialnímu rozvrhu, tj. transakce lze uspořádat tak, že dávají stejný výsledek jako při jejich sekvenčním vykonávání.

Problém je, jak poznat že jsou dva rozvrhy uspořádané.

Konflikty

• read-read - v pořádku - nekonfliktní operace
• write-read (WR): T1 write, T2 Read - čtení necommitnutých dat
• read-write (RW): T1 read, T2 write - neopakované čtení
• write-write (WW): přepsání necommitnutých dat
  
  Pozorování: Nekonfliktní operace nám nemění konečný stav rozvrhu

Definice: Rozvrhy jsou konfliktně ekvivalentní pokud sdílí konfliktní pár

Definice: Rozvrh je konfliktně uspořádaný pokud je konfliktně ekvivalentní pro nějaký uspořádaný rozvrh (pro tu stejnou transakci)

Pozorování: Pokud rozvrh je konfliktně uspořádaný, pak je uspořádaný

Potřebujeme ale stále nějak rozpoznat jestli je rozvrh konfliktně uspořádané

Definice: Precedenční graf, kde
- vrcholy jsou commitnuté transakce
- hrany reprezentují RW, WR, WW konflikt na rozvrhu
Platí: Rozvrh je konfliktně uspořádaný, pokud je graf acyklický


Teď víme kdy je rozvrh konfliktně uspořádané a kdy ne. Nyní si zavedeme ještě přísnější pravidlo pro uspořádaní

Definice: Rozvrhy jsou pohledově ekvivalentní pokud:
- Transakce $T_i$ čte iniciální hodnotu $X$ v jednom rozvrhu, právě tehdy když, čte původní hodnotu v druhém rozvrhu (Stejné původní čtení)
- Operace $O_i$ v transakci $T_i$ čte hodnotu $X$, vyprodukovanou operací $O_j$ v transakci $T_j$ právě tehdy když čte stejnou hodnotu v druhém rozvhru (Stejná závislost při psaní)
- Transakce $T_i$ píše finální hodnotu $X$ do jednoho rozvrhu právě tehdy když píše původní hodnotu v druhém rozvrhu (Stejné konečné write)
Definice Rozvrh je pohledově uspořádaný, pokud je pohledově ekvivalentní s nějakým uspořádaným rozvrhem

Návod na pohledově uspořádaný

Shrnutí

Nejdřív graf, pak pokud je cyklický, tak pak pohledově uspořádání.

POZOR: Při určování pohledově uspořádaný, tak initial read znamená, že nebylo před ní, žádný write. Pokud v tabulce nebudeme mít transakci, to znamená, že u téhle transakce nezáleží na pořadí, tzn. že může mít jaké pořadí chce.

Zotavitelnost (Recoverability):

Rozšířili jsme transakční model o operaci, ABORT. Přináší to ale svoje rizika:

Dostáváme zde nezotavitelný rozvrh. Tohle nám ničí v #ACID durability.

Definice: V zotavitelném rozvrhu transakce T je commitnutá po tom, co všechny ostatní transakce, ovlivňující T jsou commitnuté
Video s příkladem

Jak zjistit jestli je rozvrh zotavitelný? Pokud je v #Strict 2PL. Také funguje na převod z nezotavitelného na zotavitelný

Uzamykací protokoly

Zamykání databázových entit se používá ke kontrole pořadí čtení a zápisů, a také k zabezpečení konfliktového uspořádání.

Definice: Exkluzivní zámek:

• $X(A)$, zamyká A, tak, že čtení a zápis je povolen pouze autorovi/vlastníkovi

• Může být povolen pouze jedné transakci
  Definice: Sdílený zámek

• $S(A)$, pouze čte povolené A.

  • Vlastník zámku může číst a je si jistý, že se A nemůže změnit

• Může být sdíleno napříč transakcemi
  Definice: Odemknutí zámku $U(A)$

?? Nejsem si jistý ale $S\subseteq X$

Dobře formátované transakce

Transakce je dobře formátovaná, právě tehdy když

• Před čtením z A transakce si požádala a získala aspoň o sdílený zámek.
• Před zápisem do A transakce si požádala a získala aspoň o exkluzivní zámek.
• Nakonci transakce jsou všechny zámky odemčené.
  Zámky mohou být požádny explicitně, nebo doplněny implicitně rozvrhem.
  

Dvoufázový uzamykací protokol (2PL)

2PL přidává navíc jedno pravidlo k dobře formátovaným transakcím.

• Transakce si nemůže požádat o zamykání, pokud už odemknul jeden.

Dvě fáze: Zamykání a odemykání

Vlastnosti 2PL

• Zajistí, že precedenční graf je acyklický $⟹$ konfliktně uspořádaná transkace
• Nezajišťuje #Zotavitelnost (Recoverability)

Strict 2PL

Přidává následující pravidla

• Pokud transakce chce číst (zapisovat) na entitě A, tak musí nejdříve získat sdílený (exkluzivní) zámek.
• Všechny zámky se odemknou na konci transakce
  

Vlastnosti Strict 2PL

Podobně jako v #Vlastnosti 2PL navíc s

• zajištění #Zotavitelnost (Recoverability)
  

Blokování

1. Popis:
   • Blokování (Deadlock): Situace, kdy dvě nebo více transakcí čekají na uvolnění zdrojů držených jinými transakcemi, což vede k nekonečnému čekání.
   • Řešení: Použití detekce blokování a rollbacku jedné z transakcí.