Zusammenfassung

  • RFC 2371 standardisierte eine enge Zwei-Phasen-Einigung zwischen Transaktionsmanagern, nicht den Transport oder die Autorisierung der Geschäftsanfragen.
  • PREPARED und COMMITTED waren belastbare, aber begrenzte Nachweise: Sie bewiesen weder die Teilnahme aller vorgesehenen Arbeiten noch den Empfang des Ergebnisses durch den Aufrufer.

Zwei Leitungen statt einer allwissenden Transaktion

RFC 2371 erschien im Juli 1998 und beschrieb das Transaction Internet Protocol, TIP, als einfaches Zwei-Phasen-Commit-Protokoll. Bestellung, Buchung oder Überweisung liefen über ein Anwendungsprotokoll. Auf einer zweiten Leitung einigten sich die beteiligten Transaktionsmanager auf Commit oder Abbruch. Die Spezifikation nannte dies das „two-pipe model“.

Damit musste TIP weder Geschäftsvokabular noch Datenformate vereinheitlichen. Vorhandene Anwendungen konnten ihre eigene Kommunikation behalten und nur eine kleine Koordinationssprache teilen. TIP sollte auch nicht alle bestehenden Commit-Protokolle verdrängen.

Die Trennung setzte eine klare Beweisgrenze. Ein Manager konnte korrekt COMMITTED melden, obwohl der Kunde keine Bestätigung erhalten hatte, eine vorgesehene Anfrage nie gesendet wurde oder die Anwendung ihre Arbeitseinheit falsch abgrenzte. Korrekte Koordination reparierte keine Lücke im Anwendungskanal.

Die Anwendung zog die Grenze

Im Einkaufsbeispiel verbindet ein lokaler Manager mehrere entfernte Manager, damit Bestellungen gemeinsam abgeschlossen werden. TIP schützt die atomare Entscheidung der tatsächlich eingetragenen Teilnehmer. Welche Arbeit dazugehört und wann COMMIT beginnen darf, bestimmt die Anwendung.

RFC 2372 machte die Folge deutlich: Im Zwei-Leitungs-Modell kann TIP die Reihenfolge aller Anwendungsnachrichten nicht sicher erzwingen. Die Anwendung darf nicht committen, solange Aufrufe offen sind, und keinen Erfolg melden, bevor ihr lokaler Manager registriert wurde. Ein erwarteter, aber nie eingetragener Teilnehmer liegt außerhalb der Garantie.

„Die eingetragene Menge war atomar“ bedeutet daher nicht: „Die gesamte beabsichtigte Geschäftsarbeit war enthalten.“

Die TIP-URL war ein Treffpunkt

Der Kontext konnte per PUSH oder PULL weitergegeben werden. Bei PUSH ordnete der übergeordnete Manager die Zuordnung beim untergeordneten an. Bei PULL übermittelte die Anwendung eine TIP-URL; der Empfänger verwendete Adresse und Transaktionsreferenz zur Teilnahme.

Die URL sollte für alle Zeiten weltweit eindeutig sein, das Verfahren blieb implementationsabhängig. UUIDs waren nur eine mögliche Technik; das spätere RFC 4122 war kein rückwirkend vorgeschriebenes Format. TIP selbst führte die URL nicht aus. Sie wurde im Anwendungskanal transportiert.

Eine Referenz zu besitzen, bewies somit weder erfolgreichen PULL noch Berechtigung oder lokalen Commit. Die URL koordinierte eine Begegnung; sie quittierte kein Geschäft.

PREPARED schuf eine dauerhafte Verpflichtung

TIP lief üblicherweise über TCP, konnte TLS aushandeln und mehrere Transaktionen auf einer Verbindung multiplexen. Zustände wie Initial, Idle, Begun, Enlisted, Prepared, Multiplexing, TLS und Error begrenzten die zulässige Unterhaltung zwischen Managern. Sie beschrieben nicht den vollständigen Geschäftsablauf.

PREPARED bedeutete, dass der untergeordnete Manager genügend Wiederherstellungsdaten dauerhaft gespeichert hatte, um die spätere Entscheidung zu erfüllen. Ein gescheitertes Prepare bedeutete nicht automatisch ABORT. Eine vorbereitete Transaktion band Ressourcen und Wiederherstellungsverantwortung, bis ihr Ergebnis feststand.

Auch COMMIT hatte einen engen Sinn: die Entscheidung des Koordinators über die eingetragene Menge. COMMITTED meldete das Protokollergebnis des Teilnehmers. Bis zum Geschäftsbeleg fehlten noch lokale Speicherung, Zustellung der Antwort, Darstellung und spätere Beobachtung.

Erfolg konnte ohne letzte Antwort eintreten

RFC 2372 erklärte ausdrücklich, dass ein Client das Endergebnis verpassen konnte, obwohl die Transaktion erfolgreich abgeschlossen war. Die Anwendung musste den Ausgang auf anderem Weg feststellen, etwa über ein implementationsspezifisches Protokoll. Schweigen war kein Nachweis für Abbruch; blindes Wiederholen konnte einen bereits eingetretenen Effekt duplizieren.

Dauerhafte Aufzeichnungen, RECONNECT und QUERY stellten nach Fehlern die vorbereitete Beziehung der Manager wieder her. Sie retteten die Koordinationsentscheidung, nicht die gesamte Kundenerfahrung. Die Anwendung musste Ergebnis, eigenen Zustand und angezeigte Bestätigung weiterhin abgleichen.

Sicherheit sprang nicht automatisch über die Naht

TLS war möglich, seine Verwendung blieb lokaler Politik überlassen. Das RFC warnte, dass geschützte Anwendungskommunikation durch ein ungeschütztes Commit-Protokoll unterlaufen werden konnte. Umgekehrt bewies eine gesicherte TIP-Sitzung weder Identität noch Berechtigung hinter einem Kauf.

Missbräuchlicher PULL konnte einen Abbruch auslösen. PUSH konnte viele vorbereitete Transaktionen erzeugen und Ressourcen binden. Gefälschte Wiederverbindung oder Ergebnisnachrichten konnten den Ausgang verfälschen. Das waren Autoritätsfragen des Koordinationskanals, nicht der Nachweis eines vollständigen Identitätssystems.

Die Beweiskette trennte Anwendungsanfrage, Kontextweitergabe, Eintragung, lokale Arbeit, PREPARED-Datensatz, Koordinatorentscheidung, Ressourcenänderung, Protokollantwort und schließlich Kundenbeleg sowie beobachteten Geschäftszustand. TIP stärkte die Mitte dieser Kette.

Mit Lu Hengs „Minimum Initial Specification“ wird diese Enge zur Stärke: Nur die notwendige Einigung wird standardisiert, ohne jede Anwendungssemantik zu übernehmen. Running-Code Primacy verlangt dauerhafte Datensätze, Übergänge und Wiederherstellung statt bloßer Bezeichnungen. Reality Layers verbieten, COMMIT, COMMITTED, Bildschirmanzeige und späteren Kontostand als dieselbe Tatsache zu melden.

RFC 2371 lieferte einen wertvollen Beleg des Koordinationssystems. Es machte daraus keinen vollständigen Geschäftsbeleg.