6.3 Verteilte Transaktionen Situation: Fragmentierung: Ein Datenbestand ist über mehrere Stationen verteilt (z.B. verteilte Datenbank, verteiltes Dateisystem, ...) d.h. in Fragmente aufgeteilt, für die jeweils ein Server zuständig ist. Auf diesem Datenbestand soll eine Operationsfolge "sicher" ausgeführt werden. vs6.3

Buchung einer Pauschalreise: Fragment Hotels + Fragment Flüge z.B.: Buchung einer Pauschalreise: Fragment Hotels + Fragment Flüge Konsistenzforderung: - keine Hotelbuchung ohne passende Flugbuchung - keine Flugbuchung ohne passende Hotelbuchung Überweisung: Fragment Bank A + Fragment Bank B Konsistenzforderung: - Es geht kein Geld verloren und es kommt keines hinzu vs6.3

 Operationen sollten transaktional ausgeführt werden Transaktion BEGIN . . . . . [ABORT] . . . . . COMMIT sichert die Eigenschaften Atomicity - Atomarität: alles oder nichts Consistence - Konsistenz: Invariante bleibt gewährleistet Isolation - Serialisierbarkeit bei nebenläufigen Zugriffen Durability - Persistenz: Daten bleiben dauerhaft erhalten vs6.3

Serialisierbarkeit Isolation: Transaktionen sollen voneinander unabhängig sein, im Interesse der Performanz sollen sie jedoch so "nebenläufig wie möglich" ausgeführt werden Serialisierbarkeit: Der Effekt der nebenläufigen Ausführung mehrerer Transaktionen soll der gleiche sein, als wären die Transaktionen nacheinander ausgeführt worden vs6.3

x = 0; x = x+1; x = x+2; x = x+3; x = 0; x = x+1; x = x+2; x = x+3; Transaktion T1: begin x = 0; x = x+1; commit Transaktion T2: begin x = 0; x = x+2; commit Transaktion T3: begin x = 0; x = x+3; commit Ausführungs- reihenfolge 1: x = 0; x = x+1; x = x+2; x = x+3; Ausführungs- reihenfolge 2: x = 0; x = x+1; x = x+2; x = x+3; Ausführungs- reihenfolge 1: x = 0; x = x+1; x = x+2; x = x+3; serialisiert (x==3) nicht serialisiert aber OK (x==3) nicht OK (x==5) vs6.3

6.3.1 Serialisierbarkeit durch Ausschlusssynchronisation nur praktikabel für kleine fragmentierte Objekte, nicht für ganze Datenbanken! Möglichkeiten:  Verteilter Ausschluss (5.4 Sperrsynchronisation durch zentralen Koordinator, virtuellen Token Ring oder verteilte Warteschlange) zu strikt angesichts lesender vs. schreibender Operationen vs6.3

 Verteilter R/W-Ausschluss: a) In virtuellem Ring kreisende Marke (5.4.2) trägt Zähler m = Anzahl der gerade aktiven lesenden Operationen; schreibwillige Operation muß auf Marke mit m = 0 warten und diese festhalten. Nachteil: strikte Bevorzugung der Leser vs6.3

b) Virtueller Ring von n Stationen, kreisende Marke enthält m „Stimmen“ (anfangs m = n); festgelegte Quoren für Lese- bzw. Schreibrecht Leser braucht r Stimmen Schreiber braucht w Stimmen, mit folgenden Bedingungen für r und w: r + w  n (keine Leser-Schreiber-Konflikte) n/2  w  n (keine Schreiber-Schreiber-Konflikte) ( 0  r  n ) vs6.3

C schreiben (m<5) Leser-Schreiber-Ausschluss Beispiel: n = 8 r = 4 w = 5 (m = 8) A lesen m -= 4 (4) B lesen m -= 4 (0) C schreiben (m<5) Leser-Schreiber-Ausschluss D lesen (m<4) im Unterschied zu Variante a) ... weniger Leser gleichzeitig A fertig m += 4 (4) B fertig m += 4 (8) C schreiben m -= 5 (3) D lesen (m<4) Leser-Schreiber-Ausschluss ... vs6.3

etwas bessere Fairness für Schreiber Fairness "einstellbar" Variante r = 1, w = n äquivalent zu a) Vorteile werden erkauft durch eingeschränkte Nebenläufigkeit für die Leser c) Varianten anderer Ansätze aus 5.4 vs6.3

beteilige Server starten lokale Transaktion 6.3.2 Serialisierbarkeit durch verteilte Transaktionen (sichern nicht nur Serialisierbarkeit, sondern ACID insgesamt) naiver Ansatz: beteilige Server starten lokale Transaktion Koordinator fordert sie auf Wunsch des Klienten zum Commit oder Abort auf (kein Abbruch durch andere Server möglich) Koordinator Verteiltes Objekt . . . . . . . . . . . Klienten Abbruch nötig bei z.B. Deadlock-Auflösung, optimistisches Sperrverfahren vs6.3

BEGIN: alle beteiligten Server werden zu lokalem BEGIN aufgefordert 2-Phasen-Commit-Protokoll (2PC) (nicht verwechseln mit 2-Phasen-Sperren, 2PL) beteiligte Server müssen sich bei Commit-Wunsch einig werden über Abschluss oder Abbruch der verteilten Transaktion BEGIN: alle beteiligten Server werden zu lokalem BEGIN aufgefordert ABORT: alle beteiligten Server werden zu lokalem ABORT aufgefordert COMMIT: 2PC tritt in Aktion: . . . 2-Phasen-Sperren: Transaktionen benötigen Sperren für bestimmte Objekten. Es gibt eine aufsteigende und eine absteigende Phase. In der ersten werden nur Sperren angefordert, jedoch keine freigegeben, in der zweiten umgekehrt. Kann zu Deadlocks führen. Lösung: Sperren in einer festen Reihenfolge anfordern. vs6.3

1. „Commit?“ an alle Server; Phase 1 – Abstimmen: 1. „Commit?“ an alle Server; 2. diese prüfen, ob Commit möglich wäre und antworten mit „Ja“ oder „Nein“. Phase 2 – Abschließen nach Eintreffen aller Anworten: 3. Falls alle Server mit „Ja“ geantwortet haben, „Commit!“ an alle Server, sonst „Abort!“ an alle Server; 4. diese befolgen den Befehl und quittieren. Präzisierung/weiter Absicherung unter Zuhilfenahme diverser Timeouts – siehe z.B. Coulouris et al.: Verteilte Systeme vs6.3

Geschachtelte Transaktionen (nested transactions): Die Teiltransaktionen können wiederum Teiltransaktionen haben X T11 W T1 U T12 X T Y T T21 Y T2 V Z T22 Z flache (verteilte) Transaktion verschachtelte Transaktion vs6.3

- Erhöhung des Parallelitätsgrades Vorteile: - Erhöhung des Parallelitätsgrades - Abbruch einer Kind-Transaktion muss nicht unbedingt Abbruch der Eltern-Transaktion zur Folge haben (letztere ist programmatisch darauf vorbereitet) weitere Details: Özsu/Valduriez: Principles of Distributed Database Systems vs6.3