Verteilte Transaktionen

Transaktionen, die mehr als einen Ressource-Manager umfassen

Typische Ressource-Manager sind Datenbank- oder Messaging-Systeme

Anforderungen

ACID muss wie bei nicht verteilten Transaktionen gewahrt werden

Alle RM müssen

die Transaktion erfolgreich beenden oder
alle ihre Änderungen rückgängig machen

Zwei-Phasen-Commit-Protokoll (2PC)

Umgang mit mit Systemfehlern,
z.B. Kommunikationsfehler (Netzwerkunterbrechung)
TM stürzt ab, RM stürzt ab
Sicherstellung der Atomarität

Spezifikationen

Distributed-Transaction-Processing-Modell (DTP)

TX-Spezifikation

Schnittstelle zwischen AP und TM
Das AP steuert die Transaktion: bot, commit, rollback

XA-Spezifikation

Schnittstelle zwischen TM und RM
Assoziation von Operationenen im RM mit einer Transaktion
Funktionen zur Abbildung des Zwei-Phasen-Commit-Protokolls

Überweisung Giro-/Sparkonto

Verschiedene Unternehmenseinheiten für Giro- und Sparkonten

Jeweils eigene IT-Infrastruktur

2PC - erfolgreicher Abschluss

2PC - Fehlerabbruch

Zustandsübergänge in RM

executing

RM führt Operationen durch, z. B. Änderungen an Daten
Bei Fehler kann sofort in den aborting/aborted-Zustand gewechselt werden
Nach der prepare-Aufforderung durch den TM wird bei positivem Ergebnis in den prepared-Zustand gewechselt
Der RM muss auf die Entscheidung durch den TM warten

prepared

Abhängig von der Entscheidung des TM wird die Transaktion erfolgreich beendet oder es findet ein Rückgängigmachen aller Operationen statt

aborting/aborted

Transaktion wurde abgebrochen

commiting/committed

Transaktion wurde erfolgreich beendet

Zustandsübergänge in TM

executing

TM startet commit-Bearbeitung
Sendet prepare-Meldung an alle RM
Kann aber Transaktion auch abbrechen

prepared

TM wartet auf Ergebnisse von den RM
Antworten alle RM positiv geht er in den Zustand committing über
Antwortet nur ein RM negativ geht er in den aborting-Zustand über

aborting, commiting

TM warted auf Bestätigungen

aborted/committed

Information zur Transaktion wird in den Programmstrukturen des TM gelöscht, da sie komplett abgeschlossen ist

Heuristische Entscheidungen

RM hat bei prepare mit yes geantwortet

TM stürzt ab

Alle Sperren müssen im RM gehalten werden
Andere Transaktionen auf diesem RM werden möglicherweise blockiert

Pragmatische Lösung für diesen Fall: RM können von sich aus, d. h. heuristisch, eine Entscheidung zum Ausgang der Transaktion treffen, entweder commit oder abort

Dadurch wird die Atomarität der Transaktion durchbrochen, da der TM möglicherweise eine andere Entscheidung zum Ausgang getroffen hat
In diesem Fall muss ggf. manuell wieder ein konsistenter Gesamtzustand des Systems hergestellt werden