Offen geschachtelte Transaktionen ([Gray 1981] und [Traiger 1983]) erweitern klassische Transaktionen, indem sie Kommunikation zwischen verschiedenen Transaktionsbäumen erlauben und zu diesem Zweck die Isolationsanforderung an Transaktionsbäume aufheben. Bei offen geschachtelten Transaktionen werden im Gegensatz zu geschlossen geschachtelten Transaktionen die Objektänderungen der Sub-Transaktionen bei deren Ende allgemein sichtbar. Zu diesem Zeitpunkt können beliebige andere Transaktion diese Ergebnisse lesen und weiterverarbeiten. Es existiert also eine Beschränkung der Zeitpunkte, an denen Kommunikation und damit auch Nebenläufigkeitsanomalien auftauchen können, auf Beginn und Ende von Sub-Transaktionen. Die möglichen Kommunikationspartner hingegen können nicht spezifiziert werden, da jede andere Transaktion die Ergebnisse einer Sub-Transaktion lesen kann.
Da Objekte bereits bei Beendigung einer Sub-Transaktion wieder für andere Transaktionen zugreifbar sind, werden die Möglichkeiten der Nebenläufigkeit stark erhöht. Operationen auf Objekten, die innerhalb einer länger laufenden Transaktion nur kurz benutzt werden, können in einer Sub-Transaktion durchgeführt werden. Der Zugriff durch andere Transaktionen ist sofort nach Ende der Sub-Transaktion möglich, wohingegen bei geschlossen geschachtelten Transaktionen das Objekt bis zum Ende der Toplevel-Transaktion gesperrt bleibt.
Wenn Sub-Transaktionen enden und ihre Ergebnisse allgemein freigeben, gehen sie in den Zustand committed über, d. h. die geänderten Objektzustände werden permanent gespeichert. Trotzdem sollen auch offen geschachtelte Transaktionen die Eigenschaft der Fehler-Atomarität erfüllen. Dies führt zu Problemen, da bei einem Abbruch einer Transaktion auch die Effekte aller ihrer Söhne rückgängig gemacht werden müssen, einschließlich derer, die bereits beendet sind. Es widerspräche dem Transaktionskonzept und der Eigenschaft der Permanenz, wenn systemseitig die Möglichkeit bestünde, committete Objektzustände wieder zurückzusetzen. Zur Lösung dieses Problems sieht das Konzept der offen geschachtelten Transaktionen sogenannte kompensierende Transaktionen vor.
Beispielsweise kompensiert die Auszahlung eines bestimmten Betrages von einem Konto die Einzahlung desselben Betrages auf dieses Konto.
Semantisch kompensierende Transaktionen können nicht systemseitig automatisch erzeugt werden, sondern müssen vom Applikationsprogrammierer gemeinsam mit der eigentlichen Transaktion zur Verfügung gestellt werden.
Die Anforderung, daß zwischen Transaktion und Kompensation fremde Transaktionen die benutzten Objekte bearbeiten dürfen, wirft weitere Probleme auf: In dem obigen Beispiel des Kontos ist die Auszahlung schon dann nicht mehr kompensierend, wenn zwischen Ein- und Auszahlung eine Zinsberechnung und -gutschrift stattgefunden hat. Auf dem Konto befinden sich weiterhin die Zinsen für den eingezahlten Betrag, obwohl es ihn eigentlich auf dem Konto nie gegeben hat.
Dieses Beispiel zeigt, daß vom Abbruch einer Transaktion nicht nur sie selbst betroffen ist, sondern daß der Abbruch auch Auswirkungen auf andere Transaktionen hat: Es findet eine Schadensausbreitung statt. Es gäbe jetzt die Möglichkeit, wie bei den weiter unten in Abschnitt 2.6 beschriebenen dynamischen Aktionen, die Menge der Transaktionen zu bestimmen, die aufgrund der Schadensausbreitung von dem Abbruch betroffen sind, und diese auch abzubrechen bzw. zu kompensieren. Eine weitere Möglichkeit besteht darin, eine Schadensausbreitung von vornherein zu verhindern, indem man den Anwendungsbereich der offen geschachtelten Transaktionen auf solche Transaktionen einschränkt, die untereinander kommutieren. Bei kommutierenden Transaktionen hängt der Erfolg einer Transaktion in keiner Weise von den Zuständen ab, die die benutzten Objekte zu ihrem Beginn haben. Es ist also unerheblich, ob eine andere Transaktion vorher stattgefunden hat oder nicht, und es findet daher auch keine Schadensausbreitung statt. Obwohl die Beschränkung auf kommutierende Transaktionen den Anwendungsbereich eines Transaktionskonzepts stark einschränkt, wird dieser Weg von vielen auf offen geschachtelten Transaktionen aufbauenden Konzepten gewählt. Eine weitere Diskussion des Kommutativitätsbegriffs findet sich zum Beispiel in [Weihl 1988] und [Badrinath, Ramamritham 1992].
Im Konzept der offen geschachtelten Transaktionen wird die enge Verflechtung von Nebenläufigkeitskontrolle und Fehlerbehandlung besonders deutlich: Eine korrekte Fehlerbehandlung mittels Kompensation kann nur dann erfolgreich durchgeführt werden, wenn im Bereich die Nebenläufigkeit die starke Einschränkung der Kommutativität garantiert werden kann. Da im Gegensatz zu den dynamischen Aktion die Orthogonalität dieser beiden Bereiche nicht gegeben ist, führt eine Abweichung von der Kommutativitätsforderung direkt zu massiven Problemen in der Fehlerbehandlung. Beispielsweise fordert das weiter unten in Unterabschnitt 2.4.2 beschriebene ConTract Modell nicht zwingend die Kommutativität und nimmt dafür eine unkontrollierte Schadensausbreitung für den Fall in Kauf, daß durch die Kompensation die Bedingungen für die Ausführung einer anderen Transaktion nachträglich nicht mehr gegeben sind.
Ein zusätzliches Problem bei kompensierenden Transaktionen liegt darin, daß sie auch Abbrüche zurücksetzen können müssen, die durch den Komplettausfall einer Stelle ausgelöst wurden, d. h. die kompensierende Transaktion muß dem System bei einem Neustart zur Verfügung stehen, sie muß also permanent gespeichert sein.
Offen geschachtelte Transaktionen können in gewissem Rahmen das Kooperationsprinzip realisieren, da sie Informationsfluß zwischen Aktionsbäumen zulassen. Allerdings gibt es keine Möglichkeit, die Kooperationspartner genauer zu spezifizieren, sondern Zwischenergebnisse sind für alle Transaktionen sichtbar. Die Festlegung der Kooperationspartner, also der Menge von Transaktionen, die das Zwischenergebnis lesen dürfen, ist aber wesentlich für eine praktische Realisierung des Kooperationsprinzips. Die fehlende Beschränkung der Sichtbarkeit von Objektänderungen führt auch dazu, daß das Auftragsprinzip von offen geschachtelten Transaktionen nicht realisiert werden kann, da es für dieses Prinzip grundlegend ist, daß Objektänderungen von Auftragnehmern zuerst nur für den Auftraggeber sichtbar sind.
Wenn, wie es bei Sagas der Fall ist, die Kommutativität von Komponenten unterschiedlicher Sagas zwingende Voraussetzung ist, kann trotz früher Freigabe von Objektänderungen keine echte Kooperation stattfinden: Kooperation beinhaltet, daß ein Informationsfluß über die Objekte von einer Transaktion zu einer anderen stattfindet. Aufgrund des Objektzustands, den die eine Transaktion geschrieben hat, fällt die lesende Transaktion dann bestimmte Entscheidungen. Genau dieses wird aber durch die geforderte Kommutativität verboten, da alle Operationen, die die lesende Transaktion durchführt, unabhängig von dem gerade gelesenen Objektzustand sein müssen.
Sagas sind also keine Realisierung des Kooperationsprinzips, sondern haben das Ziel, insbesondere bei langlebigen Transaktionen die Nebenläufigkeit zu erhöhen, indem Objekte bereits lange vor dem Ende der Transaktion wieder freigegeben und von anderen Transaktionen benutzt werden können. Voraussetzung ist allerdings die Existenz von kompensierenden Transaktionen und Kommutativität aller Komponenten aus unterschiedlichen Sagas.
Da es sich bei ConTracts um offen geschachtelte Transaktionen handelt, werden für alle Schritte kompensierende Transaktionen benötigt, um die Fehler-Atomarität der ConTracts zu gewährleisten. Die bei Sagas noch geltende Forderung, daß alle Komponenten unterschiedlicher Sagas kommutieren müssen, um sicher zu stellen, daß eine kompensierte Komponente keine Auswirkungen auf andere Sagas hat, ist im ConTract Modell in dieser Stärke aufgehoben: Der Applikationsprogrammierer kann für jeden Schritt Eingangsbedingungen, sogenannte Invarianten, angeben. Ein Schritt S1 ist nur dann von der Kompensation eines anderen Schritts S2 betroffen, wenn nach dessen Kompensation die angegebene Invariante nicht mehr erfüllt ist. Falls dies aber der Fall ist, muß auch der ConTract, zu dem der Schritt S1 gehört, kompensiert werden. Dieses Verhalten, bei dem eine Kompensation eine weitere auslöst, die ihrerseits wiederum Kompensationen auslösen kann, wird kaskadierende Kompensation genannt und kann schnell dazu führen, daß eine Vielzahl von ConTracts aufgrund eines einzelnen Abbruchs kompensiert werden müssen. Im ConTract Modell ist kein Mechanismus vorgesehen, kaskadierende Kompensationen zu beschränken oder auch nur bei einem Abbruch die Menge der betroffenen ConTracts zu bestimmen.
Durch die Aufhebung der Kommutativitätsforderung erlaubt das ConTract Modell echte Kooperation zwischen ConTracts, da hier ein Schritt wirkliche Entscheidungen aufgrund von Objektänderungen eines Schritts aus einem anderen noch laufenden ConTract fällen kann. Wie schon bei offen geschachtelten Transaktionen beschrieben, ist auch hier keine Spezifikation der Kooperationspartner möglich.
Das ConTract Modell bietet die Möglichkeit der Kooperation zwischen ConTracts, besitzt aber einige Nachteile, die von dem ihm zugrundeliegenden Konzept der offen geschachtelten Transaktionen herrühren: die fehlende Spezifikation von Kooperationspartnern und die notwendige Existenz von Kompensationen für jeden Schritt. Außerdem ist die Behandlung von kaskadierenden Kompensationen nicht umfassend gelöst.