Zusammenfassung

  • In Argus umschloss ein Guardian Prozesse, Objekte und Wiederherstellungsverantwortung; eine atomare Action machte Änderungen beteiligter wiederherstellbarer Objekte serialisierbar und ganz oder gar nicht wirksam.
  • Ein Commit bewies nicht, dass ein externes Gerät, ein menschlicher Ablauf oder nicht verwaltete Ein-/Ausgabe abgeschlossen war. Er identifizierte auch nicht die Person oder den Geschäftszweck hinter dem Aufruf.

Der Commit ist grün, doch die Maschine steht still

Man stelle sich einen Handler vor, der ein dauerhaftes Steuerobjekt ändert und anschließend ein Gerät außerhalb von Argus zum Handeln auffordert. Die Topaction erreicht eine eindeutige Entscheidung. Alle beteiligten Guardians stimmen zu. Neue Versionen stabiler Objekte werden gespeichert. Der Aufrufer erhält Erfolg.

Trotzdem bewegt sich die Maschine nicht.

Das widerspricht dem Transaktionsergebnis nicht. Argus gibt ein starkes Versprechen für die in die Action aufgenommenen wiederherstellbaren Objekte, aber keines für ein nicht beteiligtes Gerät. „Commit“ klingt nach endgültigem Abschluss. In der Arbeit von Barbara Liskov und dem Argus-Team war es dagegen eine präzise begrenzte Eigenschaft von Sprache und Laufzeit.

Der Aufsatz Guardians and Actions von 1983, verfasst von Liskov und Robert Scheifler, verband zwei Abstraktionen. Ein Guardian bündelte Ressourcen, Objekte und Prozesse eines verteilten Programms auf einem Knoten und übernahm ihre Wiederherstellung. Eine Action bündelte Operationen, die seriell erscheinen und entweder gemeinsam einen neuen Zustand erzeugen oder den früheren wiederherstellbaren Zustand bewahren sollten. Fehlerbehandlung wurde damit von improvisierten Anwendungskonventionen zu einer begründbaren Systemleistung.

Damit entstand zugleich eine Beweisgrenze: Innerhalb der Teilnehmermenge hatte der Commit Autorität. Außerhalb brauchte es einen weiteren Nachweis.

Ein Wiederherstellungsbereich, kein Wächter der ganzen Welt

Ein Guardian ähnelte einem Modul, dessen Lebensdauer über einen einzelnen Prozess hinausging. Er enthielt Objekte, führte Prozesse aus und bot anderen Guardians Handler an. Nach einem Knotenausfall konnte sein wiederherstellbarer Zustand rekonstruiert werden; flüchtiger Zustand wurde neu initialisiert. Dadurch ließ sich die Verantwortung für Wiederherstellung lokalisieren.

Der Name verführt zu der Vorstellung eines allwissenden Sicherheitsmonitors. Das wäre zu weit. Der Guardian kapselte Programmressourcen und Wiederherstellung, nicht jede Datei, jedes Gerät, jede Person und jeden Dienst im Umfeld der Organisation.

Das Speichermodell zeigt die Grenze. Stabile Variablen waren Wurzeln für resiliente Objekte. Vor dem Commit einer Topaction musste der neue Zustand geänderter stabiler Objekte stabil gespeichert werden. Flüchtige Variablen wurden bei der Wiederherstellung neu gesetzt. Ein Verweis aus einer stabilen Variablen machte ein nicht resilientes Ziel nicht automatisch transaktional dauerhaft; Objekttyp und Wiederherstellungsimplementierung blieben entscheidend.

„Argus machte verteilte Programme zuverlässig“ ist daher zu grob. Argus machte eine definierte Klasse von Zustand unter definierten Fehlerannahmen wiederherstellbar. Die Definition erzeugte die Garantie.

Ein Handler-Aufruf ließ einen Action-Baum wachsen

Entfernte Arbeit war kein unsichtbarer Abstecher aus der Transaktion. Ein Aufruf an den Handler eines anderen Guardians erzeugte beim Aufrufer eine Call Action und am Ziel eine Activation Action. Argumente und Ergebnisse überschritten die Guardian-Grenze als Werte; der Rückweg bestimmte mit, wie die Subactions endeten.

Ein gewöhnliches return oder signal bestätigte normalerweise die Aktivierung. abort return und abort signal brachen sie ab. Eine Ausnahme war also nicht automatisch ein Transaktionsfehler. Sollte eine Ausnahme den Commit der umgebenden Arbeit verhindern, musste das Programm sie an der richtigen Action-Grenze auffangen.

Eine Subaction konnte abbrechen, ohne zwingend den Elternknoten zu zerstören. Bestätigte sie, gingen Sperren und vorläufige Versionen auf den Parent über. Das Ergebnis blieb vom Parent und letztlich von der Topaction abhängig. „Subaction bestätigt“ bedeutete nicht „unabhängig vom Aufrufer dauerhaft“.

Die Topaction bildete die Wurzel. Beim Commit koordinierte das System die Guardians, nutzte für die verteilte Entscheidung bei Bedarf Two-Phase Commit und schrieb neue Versionen der stabilen Objekte, die Action und bestätigte Nachkommen geändert hatten. Beim Abbruch fiel der transaktional verwaltete Zustand auf seine frühere Version zurück.

Diese Hierarchie verhindert drei Übertreibungen: Eine erfolgreiche Aktivierung ist noch kein Topaction-Commit; eine bestätigte Subaction ist nicht unabhängig; der Topaction-Commit belegt nichts über Nichtteilnehmer.

Orphans machten die Mehrdeutigkeit des Netzes sichtbar

Ein verteilter Aufruf kann mehrdeutig scheitern. Ein Knoten verschwindet, während anderswo weitergearbeitet wird. Der Aufrufer verliert vielleicht nur den Rückweg und weiß nicht, ob die entfernte Aktivierung gestoppt hat. Argus nannte eine Action orphan, wenn ihr Vorfahr gestorben war oder ihr Ergebnis die Abstammungslinie nicht mehr erreichen konnte.

Die Orphan-Behandlung war nicht bloß ein Timeout. Sie sollte Orphans schließlich abbrechen lassen und vor allem verhindern, dass sie nach Verlust ihrer legitimen Abstammung inkonsistente atomare Daten sahen. Das Handbuch hält eine unbequeme Tatsache fest: Ein unavailable beim Aufrufer kann mit entfernter Aktivität zusammenfallen, die noch als Orphan läuft.

Zwei Schlüsse sind gefährlich. Eine fehlende Antwort beweist nicht, dass nichts ausgeführt wurde. Ein erzwungener Abbruch im Action-System beweist nicht, dass ein unverwalteter externer Effekt zurückgenommen wurde. Die Garantie beruht auf Kommunikation über atomare Daten. Ein Motorimpuls, eine gedruckte Seite, eine bereits übergebene E-Mail oder eine menschliche Anweisung laufen nicht rückwärts, nur weil ein Argus-Vorfahr verschwunden ist.

Argus löste ein schwieriges Problem, indem es den kontrollierbaren Zustand definierte, nicht indem es die ganze Welt für transaktional erklärte.

Open Nesting war eine bewusste Ausnahme

Gewöhnliche Subactions blieben an ihren Parent gebunden. Argus bot daneben eine Nested Topaction, die unabhängig bestätigen und selbst dann bestehen konnte, wenn die äußere Action später abbrach. Das war Open Nesting.

Es eignete sich für Wirkungen, die bewusst erhalten bleiben sollten, etwa einen dauerhaften Koordinationseintrag. Doch es änderte die Beweislage. Die unabhängige Wirkung musste nach einem Fehlschlag des Parent sicher sein und die Serialisierungsbedingungen erfüllen. Ihr Fortbestand war kein rätselhaftes Leck der Atomarität, sondern eine ausdrücklich gewählte Ausnahme vom Rollback-Bereich.

Heutige Outbox-, Saga- oder unabhängige Audit-Muster entdecken diese Form erneut. Der Name ist weniger wichtig als die Disziplin: Eine getrennt bestätigte Wirkung muss benannt werden und darf nicht in der Behauptung verschwinden, die Elternoperation sei rückstandslos zurückgesetzt worden.

Der Commit entschied Zustand, nicht Identität oder Absicht

Die Action-Identität verknüpfte Arbeit für Nebenläufigkeit und Wiederherstellung. Sie authentifizierte keinen Menschen. Ein Handler konnte Argumente, Ergebnisse und Action-Abstammung kennen, ohne zu wissen, welcher Mitarbeiter oder Verantwortliche den geschäftlichen Auftrag erteilt hatte.

Serialisierbarkeit ist auch keine Zweckbindung. Zwei Anfragen können für die Objektschnittstelle gleich gültig sein, obwohl nur eine genehmigt ist. Ein Alles-oder-nichts-Update kann seine interne Invariante halten und eine Regel verletzen, die Zahlungsnetz, physischen Prozess oder Organisation umfasst. Das ist kein Mangel des Modells; man darf ihm nur keine Frage stellen, deren Beantwortung es nie versprach.

Betriebliche Nachweise brauchen deshalb Schichten. Das Transaktionsprotokoll beschreibt Guardians, wiederherstellbare Objekte, Subaction-Enden, Entscheidung und stabile Speicherung. Das Identitätsprotokoll beschreibt den Ausführungsprincipal und gegebenenfalls die genehmigende Person. Externe Belege bestätigen einen anderen Dienst, ein Gerät oder einen menschlichen Ablauf. Eine breitere Invariante verlangt Beobachtungen aus allen relevanten Bereichen.

Auch wissenschaftliche Anerkennung hat Grenzen

Liskov ist der natürliche Einstieg: Sie leitete das Forschungsprogramm und schrieb die reife Übersicht von 1988. Argus war dennoch Gemeinschaftsarbeit. Guardians and Actions stammt von Barbara Liskov und Robert Scheifler und dankt der Designgruppe, besonders Maurice Herlihy, Paul Johnson und William Weihl. Das Handbuch von 1987 nennt Liskov, Mark Day, Herlihy, Johnson, Gary Leavens, Scheifler und Weihl. Der Implementierungsaufsatz nennt Liskov, Dorothy Curtis, Johnson und Scheifler.

Diese Namen zu bewahren ist keine Zeremonie. Die Grenze zwischen Sprachidee, Wiederherstellungsprotokoll, Handbuch und laufendem System gehört zur Technikgeschichte. Ein berühmter Name darf nicht die Arbeit des ganzen Systems absorbieren, ebenso wenig wie ein Commit die Ergebnisse der ganzen Welt.

Quellen