Commit-Protokoll

Commit-Protokolle regeln die Festschreibung (Commit) von Daten, die durch eine (verteilte) Transaktion beispielsweise in einem Datenbankmanagementsystem verändert werden sollen.

Notwendigkeit und Anforderungen

Commit-Protokolle sind in verteilten Systemen und Datenbankmanagementsystemen erforderlich, um Konsistenz zu erreichen, wenn mehrere Prozesse (im Englischen in diesem Zusammenhang auch als agents bezeichnet) gemeinsam und voneinander abhängig Daten verändern. Ein Koordinator (meist der Prozess, der die Festschreibung einleitet) holt dazu die Zustimmung oder Ablehnung zur Festschreibung der Datenveränderungen aller beteiligten Prozesse ein. Nur wenn alle Prozesse zustimmen, werden die Datenveränderungen der gesamten Transaktion festgeschrieben; wenn einer oder mehrere Prozesse ablehnen, wird die Transaktion abgebrochen und die bisher vorbereiteten Datenveränderungen verworfen.

Commit-Protokolle beschreiben somit, wie Prozesse über einen Koordinator miteinander kommunizieren, wie Informationen protokolliert (geloggt) werden und wie schließlich Daten festgeschrieben werden. Dabei werden verschiedene Fehlersituationen durch das Protokoll abgefangen, wie z.B. Absturz des Koordinators während einer Phase (abhängig vom Protokoll).

Verteilte Transaktionen sollten die ACID-Eigenschaften erfüllen (genauso wie in nicht-verteilten Systemen):
Atomarität, Consistency (Konsistenz), Isolation und Dauerhaftigkeit (der vorgenommenen Änderungen)

Protokolle

Die Commit-Protokolle entscheiden sich in ihrer Phasen-Anzahl. Sie bestimmt die Möglichkeiten des Informationsaustauschs und der Fehlertoleranz.

Ein-Phasen-Commit-Protokoll

Ein eher theoretisches Ein-Phasen-Commit-Protokoll ist durch die Entscheidung des Koordinators bestimmt. Die einzige Phase ist die Commit-Phase (auch genannt Abschlussphase), in der der Koordinator den beteiligten Prozessen mitteilt, ob die Transaktion festgeschrieben (doCommit) oder abgebrochen wird (doAbort). Die teilnehmenden Prozesse haben keinen weiteren Einfluss auf die Entscheidung.

Der Nachteil liegt in der nicht vorhandenen Abstimmung, was diesem Protokoll nur dann Praxisrelevanz verleiht, wenn der Koordinator aus seiner Kenntnis diese Entscheidung treffen könnte. Dies ist nur dann möglich, wenn die einzelnen Prozesse auf jeden Fall ihre Teil-Transaktion festschreiben würden. Der einzige Abbruch-Grund wäre dann ein Abbruch seitens des auslösenden Client-Prozesses – also des Prozesses, der die Transaktion veranlasst hat. Vorteilhaft am reinen Ein-Phasen-Protokoll wäre der geringe Datenverkehr.

Zwei-Phasen-Commit-Protokoll

Ein Zwei-Phasen-Commit-Protokoll erlaubt allen beteiligten Servern mit dem Koordinator zu kommunizieren, um bei der Beendigung der Transaktion zu einer gemeinsamen Entscheidung zu kommen (Commit oder Abort).

• Abstimmungsphase: Der Koordinator sendet an alle beteiligten Prozesse eine Nachricht canCommit zur Ermittlung der Bereitschaft jedes einzelnen Prozesses zur Festschreibung für die verteilte Transaktion. Jeder angesprochene Rechner teilt ihm seine individuelle Antwort mit.
• Abschlussphase: Aufgrund der eingegangenen Antworten entscheidet der Koordinator, ob die Transaktion erfolgreich abgeschlossen (doCommit) werden kann oder abgebrochen werden muss (doAbort). Alle beteiligten Prozesse halten sich an diese Entscheidung.

Beim Zwei-Phasen-Commit besteht das grundsätzliche Problem, dass eine Störung zwischen Abstimmungsphase und Abschlussphase einen unsicheren Zustand hervorrufen kann. Beispiel: Prozess 1 und Prozess 2 melden in der Abstimmungsphase OK; der Koordinator fordert mittels des Befehls doCommit, die Transaktion abzuschließen. Prozess 1 schließt die Transaktion ab, Prozess 2 kann aber wegen einer zwischen Abstimmungsphase und Abschlussphase aufgetretenen Störung die Transaktion nicht mehr abschließen. Als Folge ist die Transaktion in Prozess 1 durchgeführt, während Prozess 2 auf die Meldung des Koordinators wartet und in diesem unsicheren Zustand blockiert.

Ein weiteres Problem entsteht durch einen Ausfall des Koordinators in der Abstimmungsfrage: Alle beteiligten Prozesse werden irgendwann geantwortet haben und warten nun auf den Koordinator. Die Prozesse befinden sich in einem unsicheren Zustand und blockieren.

Drei-Phasen-Commit-Protokoll

Ein Drei-Phasen-Commit-Protokoll ist eine Erweiterung des Zwei-Phasen-Commit-Protokolls. Es erlaubt ebenfalls allen beteiligten Prozessen mit dem Koordinator zu kommunizieren, um bei der Beendigung der Transaktion zu einer gemeinsamen Entscheidung zu kommen (Commit oder Abort).

• Wahlphase:

(a) Der Koordinator sendet eine prepare-Nachricht an alle Teilnehmer.
(b) Jeder Teilnehmer antwortet mit seiner vote-Nachricht (vote-commit oder vote-abort). Lautet seine Antwort vote-abort, dann geht der Teilnehmer unilateral in den abort-Zustand über.

• Entscheidungsvorbereitungsphase:

(a) Der Koordinator sammelt alle vote-Nachrichten von den Teilnehmern. Lauten alle auf vote-commit, so sendet er an alle Teilnehmer eine prepare-to-commit-Nachricht. Anderenfalls entscheidet er auf global-abort und teilt dies allen Teilnehmern mit.
(b) Jeder Teilnehmer, der mit vote-commit geantwortet hat, wartet auf eine prepare-to-commit oder global-abort-Nachricht des Koordinators. Trifft ein global-abort ein, dann entscheidet er auf abort. Ansonsten antwortet er dem Koordinator mit einer Bestätigung (ready-to-commit) und geht in den pre-commit-Zustand über.

• Entscheidungsphase:

(a) Der Koordinator sammelt alle Bestätigungen. Hat er alle erhalten, dann entscheidet er auf global-commit und teilt dieses den anderen Teilnehmern mit.
(b) Die Teilnehmer warten auf die commit-Entscheidung des Koordinators und führen dann die entsprechende Freigabe-Operation aus.