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

Die wünschenswerten Eigenschaften (verteilter) Transaktionen werden i.A. durch das Akronym ACID abgekürzt: Atomicity oder „Atomarität“, Consistency oder „Konsistenz“, Isolation oder „Isoliertheit von Transaktionen“ und Durability oder „Dauerhaftigkeit“. Das Commit-Protokoll ist für die Gewährleistung dieser Eigenschaften zuständig.

Je nach Commit-Protokoll müssen nicht alle der o.g. Eigenschaften verpflichtend erfüllt werden. Die Gewährleistung der „Atomarität“ der Transaktion hat normalerweise den höchsten Stellenwert. Das bedeutet, es muss sichergestellt werden, dass entweder alle oder keine der in einer Transaktion angeforderten Modifikationen durchgeführt werden.

Grundprinzip

Zur Erfüllung ihrer jeweiligen Anforderungen beschreiben Commit-Protokolle, wie die an einer Transaktion teilnehmenden Prozesse über einen Koordinator miteinander kommunizieren müssen, wie Informationen protokolliert (geloggt) werden und wie schließlich die betroffenen Daten festgeschrieben werden. Dabei werden verschiedene Fehlersituationen durch das Protokoll abgefangen, wie z. B. ein Absturz des Koordinators während einer Phase (abhängig vom Protokoll).

Varianten

In verteilten Systemen erstreckt sich eine Transaktion häufig über mehrere Prozesse (im Englischen in diesem Zusammenhang auch als agents bezeichnet), die gemeinsam und voneinander abhängig Daten verändern. Zur Gewährleistung der Atomarität ist hier ein verteiltes Commit-Protokoll erforderlich.

Zwei-Phasen-Commit-Protokolle

Das bekannteste und über X/Open XA standardisierte Verfahren ist das sogenannte „Two-Phase-Commit“ oder Zwei-Phasen-Commit (2PC). Dabei holt ein Koordinator (meist der Prozess, der die Festschreibung einleitet) in der ersten Phase des Protokolls die Zustimmung oder Ablehnung zur Festschreibung der Datenveränderungen aller beteiligten Prozesse ein (auch „Abstimmungsphase“). Nur, wenn alle Teilnehmer zustimmen, entscheidet der Koordinator auf „Commit“, ansonsten lautet die Entscheidung „Rollback“ (Zurücksetzen). Ist die Entscheidung gefallen, unterrichtet der Koordinator in der zweiten Phase („Commit Phase“) des Protokolls die Teilnehmer über das Ergebnis. Gemäß diesem gemeinsamen Ergebnis wird entweder die gesamte Transaktion zurückgesetzt, oder alle Teiltransaktionen werden zum erfolgreichen Ende geführt, indem die zwischenzeitlich gesperrten Ressourcen wieder freigegeben werden.

Algorithmus

Während der beiden Phasen werden die folgenden Nachrichten zwischen den Teilnehmern ausgetauscht^[1]:

Zwei-Phasen-Commit-Protokoll: Nachrichten zwischen Koordinator und Teilnehmer

Commit-request Phase

1. Der Koordinator sendet ein prepare an alle Teilnehmer und wartet auf Antworten aller Teilnehmer.
2. Die Teilnehmer verarbeiten die Transaktion bis zu dem Punkt, wo die Transaktion entweder mit commit oder rollback abgeschlossen wird. Dabei schreiben sie Einträge in ihr undo log und in ihr redo log.
3. Die Teilnehmer antworten mit ready, wenn die Transaktion erfolgreich war - oder sie antworten mit failed, wenn die Transaktion fehlgeschlagen ist.

Commit Phase

Wenn der Koordinator von allen Teilnehmern eine ready Meldung bekommen hat:

1. Der Koordinator sendet commit an alle Teilnehmer.
2. Die Teilnehmer schließen die Transaktion mit commit ab und geben alle Locks und Ressourcen frei.
3. Die Teilnehmer senden ein acknowledgment zurück.
4. Der Koordinator beendet die Transaktion, wenn er von allen Teilnehmern die Bestätigung erhalten hat.

Wenn zumindest einer der Teilnehmer ein failed schickt:

1. Der Koordinator sendet abort an alle Teilnehmer.
2. Die Teilnehmer schließen die Transaktion mit rollback ab (mittels des undo logs) und geben alle Locks und Ressourcen frei.
3. Die Teilnehmer senden ein acknowledgment zurück.
4. Der Koordinator beendet die Transaktion ebenso mit rollback, wenn er von allen Teilnehmern die Bestätigung erhalten hat.

Beim Zwei-Phasen-Commit besteht das grundsätzliche Problem, dass Teilnehmer zwischenzeitlich blockiert werden. Das passiert, sobald ein Teilnehmer seine lokale „Commit“-Entscheidung dem Koordinator mitgeteilt hat. Danach wartet der Teilnehmer auf die globale (gemeinsame) Entscheidung. Das wird vor allem dann problematisch, wenn der Koordinator zwischenzeitlich ausgefallen ist. In dieser Situation kann der Teilnehmer weder die gesperrten Ressourcen freigeben, noch die lokale Transaktion zurücksetzen. Allenfalls kann der Teilnehmer die globale Commit-Entscheidung von einem anderen Teilnehmer in Erfahrung bringen.

Korrektheit

Das 2PC-Protokoll garantiert die Korrektheit auch dann, wenn einzelne oder mehrere Rechner ausfallen oder wenn Netzwerkpartitionierungen auftreten, so dass die Kommunikation zwischen lauffähigen Rechnern unterbunden wird. Korrektheit bedeutet dabei: Es kann nicht vorkommen, dass eine Transaktion bei verschiedenen Teilnehmern zu unterschiedlichen Ergebnissen kommt.

Drei-Phasen-Commit-Protokolle

Zur Reduzierung der Zahl der notwendigen Protokollierungsvorgänge, der Zahl der erforderlichen Nachrichten sowie zur Steigerung der Robustheit werden in der Fachliteratur zahlreiche Varianten des 2PC-Protokolls diskutiert. So zielt etwa das sogenannte Drei-Phasen-Commit-Protokoll (3PC) darauf ab, das Risiko der Blockierung zu vermeiden. Dazu ist eine Erhöhung der Zahl der Nachrichtenrunden erforderlich, damit bei einem zwischenzeitlichen Ausfall des Koordinators das Protokoll durch einen neuen Koordinator zu Ende geführt werden kann.

Einzelnachweise

1. ↑ Alfons Kemper, André Eickler: Datenbanksysteme. Eine Einführung. 6 Auflage. Oldenbourg, München 2006, ISBN 978-3-486-57690-0.