Zwei Phasen Commit Protokoll

Two-Phase Commit (2PC) ist ein Koordinationsprotokoll, der die einhaltung von ACID Eigenschaften für verteilte Transaktionen ermöglicht.

Aufbau

Rollen

  1. Initiator
  2. Koordinator
  3. Participant

Ablauf

Phase 1: Prepare

FIXME

Phase 2: Commit/Abort

FIXME

Optimierungen

Es sind folgende Optimierungen in der 2PC Implementirung, die in der Praxis anzutrefen sind.

Presumed Abort

Wenn eine Transaktion abgebrochen wird, kann Koordinator diese Information lokal speichern 1) und natürlich auch anderen Participants mitteilen. Wenn alle Participants erreicht wurden (es müssen nicht alle erreichbar sein, Koordinator informiert sie aus Gefälligkeit) kann die Information über die Transaktion gelöscht werden. Wenn anschlißend die Anfrage nach dem Transaktionsstatus am Koordinator ankommt, wird keine Information da sein, und der Erfragende wird unterstellen, dass die Transaktion Abgebrochen war (rolled back).
Presumed Abort implementierung bedeuted daß, der Koordinator den persistenten login nicht durchführen muss bis zum Zeitpunkt seiner Entscheidung den commit anzustossen.

One-phase

Wenn nur einer Participant in die Transaktion eingebungen ist, dann gibt es keinen Grund diesen durch die prepare Phase zu jagen. Diesem Participant wird vom Koordinator ein commit geschickt.

Read-only

Wenn ein Participant der während des Transaktionsablaufes nichts verändert hat (keine oder nur lesende Operationen durchgeführt hat) eine prepare Nachricht empfängt, kann er dies dem Koordinator kenntlich machen. Der Ausganng einer Transaktion ist in diesem Fall dem Participant (Read-only-Participant geannt) egal, er muss nicht informiert werden und kann von der Zweiten Phase ausgelassen werden.

Last resource commit

Manchmal ist es nötig die nicht 2PC fähigen Participants (Resourcen) am 2PC zu beteiligen. Mit Last Resource Commit ist es möglich einen einzigen one-phase-fähigen Participant2) zu beteiligen. Der Koordintor behandelt die one-phase-resource ganz anders. Zunächst wird Prepare-Phase auf allen 2PC fähigen Rsourcen ausgeführt und dann wenn alles zum commit bereit ist wird die Kontrolle der one-phase-resource übergeben. Wenn diese erfolgreich commitet, logt der Koordinator die Entscheidung zum commiten und versucht die anderen resourcen wie gewohnt zu commiten.
Dieses kann aber trozdem zum Verlust der Atomatität3) führen, wenn die one-phase Resource ausfähllt.

Heuristische Transaktionen

Um die Atomatität der verteilten TA gewärleisten zu können ist der 2PC protoloc blokierend. Das bring aber einige nachteilige effekte mit sich, z.B. wenn der Koordinator ausfällt müssen alle Participants die im prepare-Zustand sind warten bis sie eien Status (über den Tranaktionsausgang) vom Koordinator bekommen. Das heist das einige Parcitcipants längere (oder ungewisse) Zeit blockiert bleiben, obwohl das für die manche Art der Ressourcen (bzw. Anwendungen) unakzeptabel ist. Um diese Blockierung zu duchbrechen kann es den Participants welche Prepare-Phase schon passiert haben, erlaubt sein autonome Entscheidungen zu treffen (Implementierungssache), also commit oder rollback.
Der Participant muss diese Entscheidung dauerhaft speichen, für den Fall das er noch mit der Aufforderung kontaktiert wird, die original-Transktion zum Schlus zu führen. Wenn Participant von dem Koordinator (oder Recovery-System) über den Ausgang der Transakton noch informiert wird und dieser mit einer vorherigen Entscheidung des Participants übereinstimmt, hat mein Kein Problem! Wenn nicht hat man einen heuristischen Ergebnis mit der dazugehörigen heuristischen Entscheidung (und meistens ein Problem ;-)). Heuristische Entscheidung bedeutet nicht automatisch eine heuristischen Ausgang.
Es gibt zwei Ebenen dieser heuristiken

  • Participant-to-coordinator
  • Coordinator-to-application

Es gibt dieverse Szenarien und Implementirungen. Wichtig ist das die heuristische Entscheidung “gelogt” wird .

Interposition

Interposition ist gegeben, wenn ein Participant wie ein Proxy für der TA-koordinator auftrit, dH. weitere Participants verwaltet. In großen Systemen könne so Beäume von Koordinatoren und Participants entstehen. Natürlich muss der untergeordnete Koordinator aus sienen Participants 2PC ausführen, und daher sienen eingene Logmechanismus und Recovery-system.
Die heufisten Gründe für Interposition:

  • Perfomance
  • Security und Trust
  • Connectivity - Manche Participants sind nicht direckt ereichbar bei spezifischen Koordinatoren. Ein inditreckter weg nötig.
  • Separation of Concerns - Manche Domänen und Services wollen nicht (möglich sensible) Information über Ihre interen implementirung exportieren.
1) eigentlich optional
2) Kann nur Commit und Abort, kein Prepare
3) siehe ACID
de/db/2pc.txt · Last modified: %2008/%04/%26 %13:%Apr by aho
Translations of this page:
chimeric.de = chi`s home Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0