Die in [Nett 1991] eingeführten dynamischen Aktionen setzen die Orthogonalität von Fehlerbehandlung und Nebenläufigkeitskontrolle durch. Unabhängig vom gewählten Fehlerbehandlungskonzept lassen sich so verschiedene Konzepte der Nebenläufigkeitskontrolle realisieren, wie zum Beispiel die unten beschriebenen ,,geschachtelten dynamischen Aktionen`` und die ,,dynamischen Aktionen für kooperative Anwendungen``.
Die dynamischen Aktionen setzen von den ACID-Eigenschaften (siehe Abschnitt 2.2) die Punkte der Fehler-Atomarität und der Permanenz des Effektes durch, ohne allerdings irgendwelche Anforderungen an die Isolation zu stellen. Hier liegt der grundlegende Unterschied zum klassischen Transaktionsmodell, in dem die Fehler-Atomarität nur bei Einhaltung der Isolations-Eigenschaft gewährleistet werden kann. Durch das Aufheben der Isolationsforderung bietet das Konzept der dynamischen Aktionen über verschiedene Mechanismen zur Nebenläufigkeitskontrolle die Möglichkeiten der vorzeitigen Freigabe von Ergebnissen und zur Kommunikation zwischen dynamischen Aktionen. Diese Flexibilisierung führt aber dazu, daß die Durchsetzung der Fehler-Atomarität für die Aktionsverwaltung mehr Aufwand bedeutet, als dies beim klassischem Transaktionskonzept der Fall ist. Allerdings werden bei dynamischen Aktionen keine weiteren Anforderungen an die Applikationen gestellt, im Gegensatz zu den in Abschnitt 2.4.1 vorgestellten SAGAs, bei denen zusätzlich zu den Transaktionen auch kompensierende Transaktionen existieren müssen.
Durch die vorzeitige Freigabe von Änderungen ist es möglich, daß dynamische Aktionen Ergebnisse von anderen laufenden dynamischen Aktionen lesen und aufgrund dieser Ergebnisse Entscheidungen fällen oder diese Ergebnisse anders weiterverarbeiten. Im Falle des Abbruchs der schreibenden dynamischen Aktion ist der lesenden dynamischen Aktion die Grundlage für ihre Berechnungen entzogen, ihre Ergebnisse sind also ungültig und auch die lesende dynamische Aktion muß abgebrochen werden. Der Erfolg der lesenden dynamischen Aktion hängt also von dem des Schreibers ab. Umgekehrt darf deshalb eine dynamische Aktion erst dann in den Zustand committed übergehen, wenn alle dynamischen Aktionen, von denen sie direkt oder indirekt abhängt, bereits im Zustand committed sind.
Zwischen aktiven dynamischen Aktionen können also Abhängigkeiten entstehen, die für die Durchsetzung der Fehler-Atomarität sehr wichtig sind. Dies sind die sogenannten Informationsabhängigkeiten.
Das Entstehen von Informationsabhängigkeiten führt zu einem Fehlermodell, welches zwischen drei Arten von Fehlern unterscheidet. Dabei treten die Fehler Aktionsfehler und Stellenfehler bereits beim klassischen Transaktionsmodell auf, während der kaskadierende Aktionsfehler erst bei dynamischen Aktionen betrachtet wird, da hier durch Informationsabhängigkeiten der Umfang einer Schadensausbreitung bestimmt werden kann.
Um die Fehler-Atomarität zu gewährleisten, muß die Aktionsverwaltung also bei einem Aktions- oder Stellenfehler die Menge der dynamischen Aktionen bestimmen, die von einem kaskadierenden Aktionsfehler betroffen sind, und diese auch abbrechen. Eine erfolgreiche Bestimmung setzt voraus, daß die Aktionsverwaltung entstandene Informationsabhängigkeiten speichern und bei Bedarf auswerten kann. Zu diesem Zweck enthält die Aktionsverwaltung ein Modul zur Abhängigkeitsverwaltung. Die Abhängigkeiten werden dort bei ihrer Entstehung aufgenommen und wieder entfernt, wenn die beteiligten dynamischen Aktionen committen oder abbrechen. Diese Abhängigkeitsverwaltung ist in der Lage, Abhängigkeitsmengen, wie zum Beispiel die von einem Abbruch betroffenen dynamischen Aktionen, auch in verteilten Systemen konsistent zu bestimmen. In [Theisohn 1996] wurde ein erweitertes generisches Modul zur Abhängigkeitsverwaltung vorgestellt, das neben den Informationsabhängigkeiten auch beliebige andere Abhängigkeitstypen verwalten kann. Dadurch läßt sich dasselbe Modul auch in der Nebenläufigkeitskontrolle einsetzen, um zum Beispiel wie bei den unten beschriebenen dynamischen Aktionen für kooperative Anwendungen einen Serialisierungsgraphen aufzubauen und zu überprüfen.
Ein Ziel vieler Transaktionsmodelle ist die Vermeidung des Domino-Effektes. Unter dem Domino-Effekt versteht man das möglicherweise unbegrenzte Zurücksetzen von Berechnungen aufgrund eines einzigen Fehlers. Im klassischen Transaktionsmodell wird dieser Effekt durch die Isolations-Eigenschaft verhindert: Bei einem Abbruch einer Transaktion sind nur Berechnungen dieser Transaktion betroffen und diese werden auf einen definierten Wert zurückgesetzt, nämlich auf den Wert zu Beginn der Transaktion.
In [Nett 1991] und [Nett, Mock 1995] wurde gezeigt, daß der Domino-Effekt auch bei den dynamischen Aktionen trotz Aufhebung der Isolations-Eigenschaft und den deshalb möglichen kaskadierenden Aktionsfehlern nicht auftreten kann: Dynamische Aktionen garantieren die Existenz und Fortschreibbarkeit der sogenannten Commitlinie. Die Commitlinie repräsentiert dabei für alle Objekte den jeweils letzten Zustand, der nicht mehr aufgrund irgendeines Fehlers invalidiert werden kann, und beschreibt damit den gesicherten Berechnungsfortschritt. Durch das Commit-Ereignis einer dynamischen Aktion wird die Commitlinie für alle von ihr geänderten Objekte fortgeschrieben, da dynamische Aktionen die Eigenschaft der in [Nett, Mock 1995] eingeführten Commit-Korrektheit erfüllen, die besagt, daß keine dynamische Aktion nach ihrem Commit-Ereignis noch invalidiert werden kann.
Um die Commit-Korrektheit sicherzustellen, darf eine dynamische Aktion im Zustand committed nie von anderen, noch nicht committeten dynamischen Aktionen informationsabhängig sein. Dieses wird dadurch garantiert, daß ein Commit-Ereignis nur dann erfolgreich ist, wenn alle dynamischen Aktionen, von der die committende dynamische Aktion abhängt, bereits im Zustand committed sind, oder gleichzeitig mit ihr in diesen Zustand übergehen.
Die Commit-Korrektheit führt also dazu, daß eine dynamische Aktion nicht autonom bei Ende ihrer Berechnungen in den Zustand committed übergehen kann, sondern gegebenenfalls darauf warten muß, daß dynamische Aktionen, von denen sie abhängt, bereit sind, auch in den Zustand committed zu wechseln. Bis zum Commit-Ereignis durchläuft eine dynamische Aktion also zwei Abschnitte: Die aktive Zeit, in der sie Berechnungen durchführt und auch selbständig abbrechen kann, und die Zeit, in der sie keine eigenen Berechnungen mehr durchführt und daher nur noch durch Stellen- und kaskadierende Aktionsfehler abgebrochen werden kann. Das Ende der eigenen Berechnungen wird durch den Wechsel in den Zwischenzustand completed markiert. Dieser in [Nett, Grosspietsch et al. 1985] eingeführte Zustand besagt, daß die dynamische Aktion keine Berechnungen mehr durchführt und bereit ist, in den Zustand committed zu wechseln. Dieser Wechsel findet aber erst dann statt, wenn die dynamische Aktion nicht mehr von einem kaskadierenden Aktionsfehler betroffen werden kann und wenn alle Objektänderungen zum Schutz vor Stellenfehlern permanent gespeichert sind. Es ergeben sich für dynamische Aktionen also die in Abbildung 2.2 gezeigten Zustände.
Nach der Beschreibung der Fehlerbehandlung sollen jetzt zwei wichtige Nebenläufigkeitskonzepte im Rahmen der dynamischen Aktionen dargestellt werden: die geschachtelten dynamischen Aktionen und die dynamischen Aktionen für kooperative Anwendungen.
Geschachtelte dynamische Aktionen haben eine Baumstruktur, wie sie schon in [Moss 1981] für die geschlossen geschachtelten Transaktionen vorgeschlagen und in Abschnitt 2.3 beschrieben wurde. Im Gegensatz zu diesen, bei denen für jeden Transaktionsbaum weiterhin die Isolation garantiert wird, erlauben geschachtelte dynamische Aktionen die vorzeitige Freigabe von Ergebnissen. Hier wird lediglich zur Vermeidung von Nebenläufigkeitsanomalien das Konsistenzkriterium der Serialisierbarkeit von Aktionsbäumen gefordert.
Die geschlossen geschachtelten Transaktionen wurden eingeführt, um innerhalb von Transaktionen die Parallelität zu erhöhen und Transaktionen vor vollständigen Abbrüchen zu schützen. Dieser Schutz vor vollständigem Abbruch kommt dann zum Tragen, wenn bei verteilten Transaktionen eine Stelle ausfällt oder wenn die Applikation gezielt einen Teil der Berechnung abbrechen will. Zusätzlich hierzu bietet die Schachtelung von dynamischen Aktionen auch den Schutz vor kaskadierenden Aktionsfehlern, eine sehr wichtige Eigenschaft. Durch die vorzeitige Freigabe kann sich eine dynamische Aktion von einer anderen aktiven dynamischen Aktion abhängig machen. Wenn diese nun abgebrochen wird, muß aufgrund der Fehler-Atomarität auch die abhängige dynamische Aktion abgebrochen werden, wodurch möglicherweise lange Berechnungen, die gar nicht direkt von der abgebrochenen dynamischen Aktion abhängen, zurückgesetzt werden. Wurde aber von einem Sohn auf die fraglichen Objekte zugegriffen, so wird nur dieser abgebrochen, die anderen Berechnungen bleiben bestehen und die Applikation kann geeignet auf den Abbruch des Sohnes reagieren.
Das Konsistenzkriterium für geschachtelte dynamische Aktionen ist die Serialisierbarkeit, wie sie in [Beeri, Bernstein et al. 1989] eingeführt wurde. Bei den geschlossen geschachtelten Transaktionen wurde noch die Isolation gefordert, die dazu führte, daß Objektänderungen erst am Ende der Toplevel-Transaktion allgemein sichtbar wurden. Serialisierbarkeit hingegen erlaubt, daß Objektänderungen schon früher sichtbar gemacht werden können, wodurch die Nebenläufigkeit von dynamischen Aktionen stark erhöht werden kann. Serialisierbarkeit wird garantiert, wenn sich dynamische Aktionen zweiphasig verhalten, wie es weiter unten bei der Diskussion des Sperrverfahrens beschrieben wird.
Bei geschachtelten dynamischen Aktionen müssen Aktionsbäume und Aktionsteilbäume, bei denen nicht einer den anderen enthält, untereinander serialisierbar sein. Das bedeutet im einzelnen:
Genau wie Toplevel-Aktionen können Brüder unabhängig parallel voneinander ablaufen, sofern sie nicht auf gemeinsame Objekte zugreifen.
Aktionsbäume müssen nach außen weiterhin wie eine einzige flache dynamische Aktion serialisierbar sein. Aus diesem Grund dürfen Zwischenergebnisse von Sohnaktionen nicht direkt für alle dynamischen Aktionen sichtbar werden, sondern zuerst nur für den Vater. Dieser kann dann die Änderungen entweder weiter verbergen, um zum Beispiel diese durch einen weiteren Sohn bearbeiten zu lassen, oder in der Schachtelungshierarchie für weitere Vorfahren sichtbar machen. Erst wenn eine Toplevel-Aktion eine Änderung sichtbar macht, ist sie für alle anderen dynamischen Aktionen auch sichtbar.
Durch die eben beschriebenen Sichtbarkeitseigenschaften realisieren geschachtelte dynamische Aktionen das Auftragsprinzip. Das Kooperationsprinzip kann durch geschachtelte dynamische Aktionen nicht realisiert werden, da die durchgesetzte Serialisierbarkeit von dynamischen Aktionen einer Ebene Informationsfluß nur in eine Richtung zuläßt. Das Kooperationsprinzip fordert aber zwischen Kooperationspartnern Informationsfluß in beide Richtungen.
Für Subaktionen wird die Fehler-Atomarität garantiert. Um auch die Permanenz garantieren zu können, darf eine dynamische Aktion erst dann in den Zustand committed übergehen, wenn sie garantiert nicht mehr abgebrochen werden kann. Eine Sohnaktion kann aber solange noch abgebrochen werden, wie ihr Vater noch nicht committed hat. Der Sohn geht bei seinem Ende deshalb zuerst in den Zustand completed über und wechselt erst zusammen mit dem Vater nach committed.
Bei der Behandlung von kaskadierenden Aktionsfehlern muß zusätzlich zum oben beschriebenen Verfahren für Väter und Söhne folgende besondere Beziehung beachtet werden: Der Abbruch eines Vaters führt immer zum Abbruch aller Söhne, wohingegen der Abbruch eines Sohnes nicht erzwingt, daß der Vater auch abbricht.
Serialisierbarkeit läßt sich nach [Eswaran 1976] erreichen, indem Sperren nach dem sogenannten nicht-strikten Zwei-Phasen-Sperrprotokoll vergeben werden. Die aktive Zeit einer dynamischen Aktion läßt sich hiernach in zwei Phasen einteilen: die wachsende Phase, in der eine dynamische Aktion Sperren nur anfordern, und die schrumpfende Phase, in der sie die Sperren nur freigegeben darf. Der Wechsel zwischen beiden Phasen wird Lockpunkt genannt. Sowohl Toplevel- als auch Subaktionen müssen sich konform zum nicht-strikten Zwei-Phasen-Sperrprotokoll verhalten.
Um zu verhindern, daß Zwischenergebnisse zu früh ,,nach außen`` sichtbar werden, werden Sperren bei der Freigabe durch eine Sohnaktion nicht tatsächlich freigegeben, sondern an den nächsten Vorfahren vererbt, der noch nicht den Lockpunkt erreicht hat (siehe hierzu [Nett, Weiler 1994]).
Es ist möglich, daß Väter und Söhne gleichzeitig in Konflikt stehende Sperren auf dasselbe Objekt besitzen. Zur Synchronisation zwischen den dynamischen Aktionen und auch bei mehreren parallelen Prozessen innerhalb einer dynamischen Aktion wird eine zweite Ebene von Sperren eingeführt, die Benutzungssperren, für die die gleichen Konfliktregeln gelten.
Sperren werden nach folgenden Regeln gewährt und freigegeben:
Sofern die dynamische Aktion einen Vorfahren hat, der sich noch in der ersten Phase befindet, erbt der nächste Vorfahre die Sperre. Hält dieser Vorfahre bereits eine Sperre, besitzt er dann die stärkere. (Eine Schreibsperre ist stärker als eine Lesesperre.)
Ferner wird vorausgesetzt, daß Applikationen sich konform zu den Sperren verhalten: Zugriffe auf die Objekte dürfen nur stattfinden, wenn die entsprechende dynamische Aktion die entsprechenden Sperren besitzt.
Serialisierbarkeit ist eine wichtige Eigenschaft, die unerwünschte Effekte wie die Nebenläufigkeitsanomalien vermeidet. Allerdings verhindert sie auch Kooperation, die typischerweise zu folgenden nicht-serialisierbaren Abläufen führt: Aktion A ändert ein Objekt, Aktion B liest die Änderung und schreibt erneut einen Wert, den Aktion A wieder liest. Die Aufhebung der Serialisierbarkeit ist für Kooperation also notwendig, erfordert aber, daß der Applikationsprogrammierer das konsistente Verhalten der dynamischen Aktion bezüglich anderer, nicht-serialisierbarer dynamischer Aktionen sicherstellen muß. Da dieses zwar für bekannte Kooperationspartner möglich, im allgemeinen aber nicht zu leisten ist, muß die Serialisierbarkeit so weit wie möglich durch die Aktionsverwaltung garantiert und nur gezielt für kooperierende dynamische Aktionen aufgehoben werden. Kooperierende dynamische Aktionen werden der Aktionsverwaltung durch Kooperationsgruppen mitgeteilt. In [Mock 1994] wird auch die Möglichkeit individueller Kooperationsfunktionen besprochen, die das Kooperationsverhalten jeder einzelnen dynamische Aktion festlegen. Da Kooperationsgruppen in der Praxis leichter zu realisieren sind und meistens das gewünschte Kooperationsverhalten ausreichend genau beschreiben, wird die dynamische kooperative Serialisierbarkeit hier auf Basis der Kooperationsgruppen eingeführt.
Serialisierbarkeit wird hier nicht mehr mit Hilfe von Zweiphasigkeit durchgesetzt, sondern dynamisch überprüft und durch Einschränkung der zugreifbaren Objekte in bestimmten Phasen sichergestellt. Zur Überprüfung der Serialisierbarkeit wird in der ohnehin zur Verwaltung von dynamischen Aktionen vorhandenen Abhängigkeitsverwaltung (siehe [Theisohn 1996]) mit Hilfe der sogenannten Konfliktabhängigkeiten der Serialisierungsgraph aufgebaut.
Zwischen zwei dynamischen Aktionen existiert eine Konfliktabhängigkeit, wenn sie jeweils Operationen ausführen, die in Konflikt stehen. Die Abhängigkeit läuft in Richtung des zeitlichen Auftretens der Operationen.
Nach [Bernstein, Hadzilacos et al. 1987] ist eine Ausführungsfolge genau dann serialisierbar, wenn der Serialisierungsgraph zyklenfrei ist. Um die gewünschte Serialisierbarkeit von Kooperationsgruppen zu gewährleisten, dürfen Zyklen nur zwischen dynamischen Aktionen derselben Kooperationsgruppe auftreten.
Die dynamische kooperative Serialisierbarkeit wird durchgesetzt, indem eine dynamische Aktion drei Phasen durchläuft, die durch die Ereignisse Bildung der Kooperationsgruppe und Validierung getrennt sind:
Von Phase zu Phase wird die Menge der zugreifbaren Objekte mehr und mehr eingeschränkt, wie Abbildung 2.4 veranschaulicht. Dies geschieht, um die bei der Bildung von Kooperationsgruppen sichergestellte Zyklenfreiheit mit dynamischen Aktionen außerhalb der Kooperationsgruppe weiter garantieren zu können.
Wenn eine dynamische Aktion in die zweite Phase gelangt, liegen garantiert alle Zyklen, an denen sie beteiligt ist, innerhalb ihrer Kooperationsgruppe. In der zweiten Phase darf eine dynamische Aktion sich nur noch von dynamischen Aktionen abhängig machen, die in der eigenen Kooperationsgruppe liegen oder schon validiert sind. Validierte dynamischen Aktionen hängen aber nur noch von anderen validierten dynamischen Aktionen ab und werden die Menge der dynamischen Aktionen, von denen sie abhängen, auch nicht mehr vergrößern. Da die dynamische Aktion selbst noch nicht validiert ist, kann so kein Zyklus mehr entstehen. Durch die Festlegung der Abhängigkeitsmenge bei der Validierung ist auch das Entstehen weiterer Zyklen in der dritten Phase ausgeschlossen.
Das Kooperationsprinzip wird durch die dynamischen Aktionen für kooperative Anwendungen realisiert, da die Eigenschaft der dynamischen kooperativen Serialisierbarkeit garantiert, daß beidseitiger Informationsfluß zwischen dynamischen Aktionen innerhalb einer Kooperationsgruppe möglich ist. Zwischen dynamischen Aktionen aus unterschiedlichen Kooperationsgruppen ist der Informationsfluß nur in eine Richtung möglich. Das Auftragsprinzip kann nicht realisiert werden, da eine Auftraggeber-Auftragnehmer-Beziehung zwischen dynamischen Aktionen erfordert, daß Ergebnisse von Auftragnehmern nur für den Auftraggeber sichtbar sind. Im Konzept der dynamischen Aktionen für kooperative Anwendungen sind Ergebnisse einer dynamischen Aktion aber immer für alle anderen dynamischen Aktionen sichtbar.
Die oben vorgestellten Mechanismen zur Fehlerbehandlung bei dynamischen Aktionen reichen vollkommen aus, um diese auch im Fall von Kooperation adäquat durchzuführen.
Da parallel zu den Konflikt- oft auch Informationsabhängigkeiten entstehen, kann es auch dort zu Zyklen kommen. Die Eigenschaft der Commit-Korrektheit verhindert, daß in einem Zyklus eine dynamische Aktion vor den anderen in den Zustand committed wechselt, da sie noch von einem kaskadierenden Aktionsfehler betroffen werden kann. Dynamische Aktionen innerhalb von Zyklen können nur in den Zustand committed übergehen, indem sie alle einen sogenannten Gruppen-Commit durchführen. Beim Gruppen-Commit wechseln alle dynamischen Aktionen gleichzeitig ihren Zustand, wodurch die Commit-Korrektheit eingehalten werden kann.
Den Wechsel der Phasen muß die dynamische Aktion der Aktionsverwaltung durch zwei entsprechende Operationen mitteilen. Diese Operationen haben nicht nur reinen Informationscharakter, wie zum Beispiel das Setzen des Lockpunktes beim geschachtelten Sperrverfahren (Abschnitt 2.6.2), sondern können in der eben beschriebenen Situation auch fehlschlagen. Für eine genaue Beschreibung beispielsweise des Validierungsprotokolls siehe [Mock 1994].
Die Sperren werden nach folgenden Regeln gewährt und freigegeben:
