Zusammenfassung

  • RFC 2372 empfahl einen prepared-recovery record vor PREPARED und einen commit-recovery record vor COMMIT im Prepared-Zustand; löschen durfte man sie erst nach jeweils benannten Auflösungsnachrichten.
  • Diese Ordnung definierte lokale Verwahrung, bewies aber weder stabile Speicherung noch Überleben eines Absturzes, richtige Identitätsrekonstruktion oder Kenntnis des Ergebnisses beim Auftraggeber.

PREPARED klingt vorläufig. Tatsächlich verliert ein Teilnehmer genau mit diesem Wort die Freiheit, nach einem Fehler allein abzubrechen. Der Übergeordnete könnte bereits alle Stimmen besitzen und den Commit beschlossen haben. Der Untergeordnete verspricht deshalb, den Vorgang noch zu kennen, wenn Socket, Prozess oder Rechner nicht mehr derselbe sind.

RFC 2372 erschien im Juli 1998 als Informational RFC, nicht als Internetstandard. Das Dokument beschrieb Anforderungen und Umsetzungshinweise zu TIP und nannte seine Zuordnung zwischen Protokoll und Log ausdrücklich beratend. Es berichtete keinen Produkteinsatz, keine Speichertechnik und keinen Crashtest. Es sagte, was gelten sollte; die laufende Implementierung musste es erst beweisen.

Vor PREPARED sollte der Untergeordnete seinen prepared record anlegen und bis ABORT, COMMIT oder QUERIEDNOTFOUND behalten. Solange er existierte, sollte er weder COMMITTED noch NOTRECONNECTED senden. Der Übergeordnete sollte nach PREPARED, aber vor COMMIT im Prepared-Zustand, seinen commit record anlegen und bis COMMITTED oder NOTRECONNECTED aufbewahren.

Damit wechselte Verwahrung. PREPARED verwandelte lokale Wahlfreiheit in eine Pflicht gegenüber dem Koordinator. COMMIT verwandelte eine Entscheidung in etwas, das nach einem Ausfall erneut gesendet werden können musste. Löschen war keine Routinepflege, sondern die Aussage, dass eine vorgeschriebene Evidenz die Pflicht beendet hatte.

Ein negatives Ergebnis konnte Abschluss belegen

Nach Verbindungsverlust konnte der Übergeordnete RECONNECT mit der Transaktionskennung des Untergeordneten senden und sie nötigenfalls aus dem Log holen. War dieser noch Prepared, antwortete er RECONNECTED. Hatte er COMMIT verarbeitet, COMMITTED gesendet und den fertigen Vorgang vergessen, antwortete er NOTRECONNECTED. Das Nein war innerhalb der richtigen Geschichte nicht zwingend ein Fehler, sondern konnte das abgeschlossene Vergessen bestätigen.

Der Untergeordnete konnte QUERY senden. QUERIEDEXISTS hieß, dass der Übergeordnete den Vorgang noch kannte und später reconnecten würde. QUERIEDNOTFOUND erlaubte den Abbruch: Der Übergeordnete konnte ABORT gesendet, ABORTED verpasst und den presumed-abort-Vorgang danach vergessen haben. Abwesenheit bekam erst durch Rolle, Zustand, Kennung und Nachrichtenfolge eine Bedeutung.

Eine wiederhergestellte TCP-Verbindung war daher keine wiederhergestellte Transaktion. Transport verband Endpunkte, rekonstruierte aber weder die richtige Kennung noch die offene Pflicht. Ein fehlender Datensatz konnte sicheren Abschluss, vermuteten Abbruch oder Verlust bedeuten. Lokale dauerhafte Identität musste mit entfernter Protokollevidenz zusammenpassen.

Die Löschbelege waren rollenspezifisch. Der Untergeordnete wartete auf Entscheidung oder auf die Abfrage, die Prepared freigab. Der Übergeordnete wartete auf die Bestätigung oder auf den genau definierten Fall eines bereits fertigen und vergessenen Teilnehmers. Neustart, Speicherknappheit, Ablaufzeit oder Zuversicht des Operators ersetzten diese Nachrichten nicht.

Lokale Timeouts konnten blockierte Ressourcen begrenzen und Deadlocks lösen. Verstrichene Zeit bewies jedoch kein Ergebnis. Ressourcenfreigabe, Protokollauflösung und nachträgliches Wissen blieben getrennte Sachverhalte.

Zwischen „anlegen“ und „dauerhaft“ lag der Speicherpfad

Was bedeutete das Anlegen konkret: Benutzerpuffer, Kernel-Cache, Journal, physisches Medium oder Replikat in einer anderen Fehlerdomäne? Welche Dauerhaftigkeit versprach die Speicherbestätigung? Konnte ein Schreibvorgang reißen? War die Kennung ohne flüchtigen Index auffindbar? Konnte ein asynchroner Sender PREPARED zu früh herausgeben?

RFC 2372 beantwortete das nicht. Es benannte weder Datenbank noch Konformitätstest oder Stromausfallexperiment. Mit Heng Lus Vorrang für laufenden Code wird die Grenze klar: Der Text bestimmt die erforderliche Reihenfolge; der Betriebsnachweis beobachtet das Schreiben, unterbricht im ungünstigen Moment, startet neu, rekonstruiert dieselbe Identität, gleicht den Peer ab und prüft die Ressource. Der RFC entwirft den Test, nicht sein Bestehen.

Auch korrekt ausgelöstes Löschen kann falsch geordnet sein. Wird der Datensatz dauerhaft entfernt, bevor die passende Zustandsänderung des Ressourcenmanagers feststeht, entsteht erneut eine Lücke. Bleibt alles für immer, wachsen Ressourcen- und Betriebsprobleme. Richtigkeit liegt in der überprüfbaren Beziehung zwischen Protokoll-, Log- und Ressourcenzustand.

Delegation verschob die Beweispflicht

Ein leichter Client konnte Koordination an einen vollwertigen Server delegieren und ohne eigenes Transaktionslog auskommen. Die Recovery-Verantwortung verschwand nicht; ihr Verwahrer wechselte. Eine Prüfung musste ihr zum Server folgen: welcher Datensatz, unter welcher Kennung, vor welcher Aussage und nach welchem Beleg gelöscht?

Der Client konnte weiterhin die letzte Commit-Antwort verlieren und das tatsächlich erreichte Ende nicht kennen. RFC 2372 überließ der Anwendung die Feststellung und erwähnte ein implementationsspezifisches Benutzerlog. Erfolgreiche Protokoll-Recovery bedeutete somit nicht automatisch ein Geschäftsergebnis für den Aufrufer.

Darauf beschränkt sich die eigene These dieses Artikels. Der bestehende Beitrag zu RFC 2371 behandelt zwei Kanäle und COMMIT als etwas anderes als einen Geschäftsbeleg. Hier geht es um die lokale Evidenzkette: prepared record, commit record, rekonstruierte Kennung und das präzise entfernte Signal, das ihr Löschen erlaubt.

Die zwei Kanäle verlangten zudem Anwendungsdisziplin. TIP sah nicht unbedingt noch laufende Anwendungsanfragen. Die Anwendung sollte commit erst nach deren Abschluss aufrufen und ihrem Partner erst positiv antworten, wenn der lokale Transaktionsmanager registriert hatte. Ein perfektes Log konnte unvollständige Geschäftsvorgänge nicht nachträglich serialisieren.

Authentizität war nicht Dauerhaftigkeit

Anwendungsauthentisierung und -autorisierung lagen außerhalb von TIP. TLS konnte ausgehandelt werden, Endpunkte authentisieren und Befehle verschlüsseln. Das schützte einen Rand der Kette, bewies jedoch weder den dauerhaften Datensatz noch Geschäftsberechtigung, Ressourcenwirkung oder Anerkennung des Ergebnisses.

Recovery brauchte vertrauenswürdigen Kanal und richtige Kennung. Eine authentisierte Anfrage zur falschen Transaktion blieb falsch; die richtige Kennung von einem Angreifer blieb gefährlich. Sicherheits-, Zustands- und Autoritätsevidenz ergänzten einander.

Heng Lus Wirklichkeitsebenen verhindern, dass Anwendungsanfrage, lokale Aktion, TIP-Zustand, Log, Speicherbestätigung, Nachricht, rekonstruierte Identität, Peer-Antwort, Ressourcenergebnis und Clientwissen zu „committed“ zusammenfallen. Eine Ebene konnte feststehen, während die nächste unbekannt blieb.

Minimale Vorgabe, lokale Entscheidung, lokaler Nachweis

Der RFC schrieb kein einheitliches Logformat, Speichersystem, API oder Bedienfeld vor. Interoperabilität verlangte gemeinsame Befehle, Rollen, Kennungen und Recovery-Bedeutung, nicht dieselbe Datenbank. Nach Heng Lus Idee der minimalen Anfangsspezifikation blieb die spätere technische Entscheidung lokal.

Diese Freiheit brachte Nachweispflicht mit sich. Der Betreiber musste zeigen, dass der Datensatz der Nachricht vorausging, Stromverlust überstand, ohne flüchtigen Index wiedererschien, an die richtige Ressource gebunden war und nur nach dem erlaubten Beleg verschwand. Der RFC beantwortete das Soll, nicht den Befund.

Auch heutige Systeme sagen vor dem Ausfall „angenommen“, „repliziert“, „bereit“ oder „autorisiert“. Jedes Wort erzeugt eine Erwartung darüber, was überlebt. Die Lehre aus RFC 2372 lautet nicht, dass ein Log die Aussage wahr macht. Sie lautet: Eine Aussage mit Folgen nach dem Fehler braucht einen dauerhaften, prüfbaren und zeitlich vorherigen Beleg.

Quellen