vs 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. Beispiel Pauschalreisen: Fragment Hotels + Fragment Flüge Konsistenzforderung verbietet Hotelbuchung ohne passende Flugbuchung Flugbuchung ohne passende Hotelbuchung

vs52  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

vs Serialisierbarkeit durch Ausschlußsynchronisation (für kleine fragmentierte Objekte, nicht für ganze Datenbanken!)  Verteilter Ausschluß (4.4  ):4.4 zu strikt angesichts lesender vs. schreibender Operationen  Verteilter R/W-Ausschluß: a) In virtuellem Ring kreisende Marke (4.4.2  ) trägt Zähler m4.4.2 = Anzahl der gerade aktiven lesenden Operationen; schreibwillige Operation muß auf Marke mit m = 0 warten und diese festhalten. Nachteil: strikte Bevorzugung der Leser

vs54 b) Virtueller Ring von n Stationen, kreisende Marke enthält m „Stimmen“ (anfangs m = n); festgelegte Quoren für Lese- bzw. Schreibrecht: 0  r  n r + w  n n/2  w  n c) Varianten anderer Ansätze aus 4.4 Leser braucht r Stimmen Schreiberbraucht w Stimmen (r = 1, w = n  äquivalent zu a)!) Vorteil: etwas bessere Fairness für Schreiber – wird erkauft mit eingeschränkter Nebenläufigkeit für die Leser

vs Serialisierbarkeit durch verteilte Transaktionen (sichern nicht nur Serialisierbarkeit, sondern ACID insgesamt) Prinzip:Koordinator steuert 2-Phasen-Commit-Protokoll (2PC) (nicht verwechseln mit 2-Phasen-Sperren, 2PL!), das auf die lokalen Transaktionssysteme aufgesetzt wird Koordinator Verteiltes Objekt Klienten BEGIN : alle beteiligten Server werden zu lokalem BEGIN aufgefordert ABORT : alle beteiligten Server werden zu lokalem ABORT aufgefordert COMMIT : 2PC tritt in Aktion:...

vs56 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 unter Zuhilfenahme diverser Timeouts – siehe z.B. Coulouris et al. 14.3)

vs57 Geschachtelte Transaktionen (nested transactions): Die Teiltransaktionen können wiederum Teiltransaktionen haben Vorteile: - Erhöhung des Parallelitätsgrades - Abbruch einer Kind-Transaktion muß nicht unbedingt Abbruch der Eltern-Transaktion zur Folge haben (letztere ist programmatisch darauf vorbereitet) (Details zu 2PC: Coulouris et al. oder Özsu/Valduriez: Principles of Distributed Database Systems, Section 12.5)