Nachdem in den beiden vorherigen Abschnitten mit den geschlossen und offen geschachtelten Transaktionen die bekanntesten Konzepte vorgestellt wurden, die jeweils nur das Auftrags- bzw. Kooperationsprinzip realisieren, werden in diesem Abschnitt einige Konzepte diskutiert, die das Ziel haben, beide Konzepte zu integrieren.
Eine naheliegende Möglichkeit der Kombination von Auftrags- und Kooperationsprinzip besteht darin, ein Transaktionskonzept zu entwickeln, das Eigenschaften der offen und der geschlossen geschachtelten Transaktionen integriert, da diese für sich jeweils das Kooperations- bzw. das Auftragsprinzip realisieren. Eine solche Integration wurde beispielsweise in dem in [Buchmann et al. 1992] vorgestellten DOM Transaktionsmodell (,,Distributed Object Management``) durchgeführt und wird hier kurz beschrieben:
Im DOM Transaktionsmodell werden Transaktionen wie in den schon beschriebenen Konzepten hierarchisch in Bäumen strukturiert. Dabei werden mit den Multitransaktionen und den Toptransaktionen zwei Typen von (Sub-) Transaktionen unterschieden.
Multitransaktionen sind Wurzeln von offen geschachtelten (Teil-) Bäumen, deren Söhne selbst wieder Multitransaktionen oder auch Toptransaktionen sein können. Dabei können alle Söhne einer Multitransaktion nebenläufig gestartet werden, es sei denn, es werden Regeln angegeben, die die Ausführungsreihenfolge der Söhne spezifizieren. Für Multitransaktionen wird Fehler-Atomarität aber nicht Isolation gefordert und entsprechend dem Konzept der offen geschachtelten Transaktionen müssen daher für alle Söhne kompensierende Transaktionen existieren. Da nur Toptransaktionen Objekte verändern dürfen, muß der Applikationsprogrammierer nur für diese Kompensationen angeben und komplette Multitransaktionen werden kompensiert, indem alle ihre bereits erfolgreich beendeten Söhne in der umgekehrten Reihenfolge der Commit-Ereignisse kompensiert werden. Söhne von Multitransaktionen werden auch danach unterschieden, ob sie vital oder nicht-vital sind: Eine Vatertransaktionen darf nur dann in den Zustand committed übergehen, wenn alle vitalen Söhne bereits in diesem Zustand sind. Nicht-vitale Söhne hingegen können abbrechen, ohne den Abbruch des Vaters nach sich zu ziehen.
Toptransaktionen sind Wurzeln von geschlossen geschachtelten Transaktionsbäumen, die entsprechend [Moss 1981] die Eigenschaften der Fehler-Atomarität und Isolation (bezüglich Brüdern) erfüllen. Toptransaktionen dürfen nur weitere Toptransaktionen als Nachfahren haben, wobei flache Transaktionen auch als Toptransaktionen gelten.
Das Auftragsprinzip wird im DOM Transaktionsmodell durch die Toptransaktionen realisiert. Da Toptransaktionen geschlossen geschachtelte Transaktionen sind, gelten für sie alle in Abschnitt 2.3 gemachten Aussagen zur Realisierung von Auftrags- und Kooperationsprinzip entsprechend.
Das Kooperationsprinzip wird durch Multitransaktionen gelöst, allerdings gelten auch hier die von den offen geschachtelten Transaktionen bekannten Einschränkungen: Kooperationspartner können nicht festgelegt werden und um wirkliche Kooperation realisieren zu können, muß auf die Kommutativität zwischen den Söhnen unterschiedlicher Multitransaktionen verzichtet werden. Die daraus resultierende Schadensausbreitung im Falle eines Abbruchs wird im DOM Transaktionsmodell nicht betrachtet.
Ferner ist die Integration beider Prinzipien nur unzureichend gelöst: Eine Transaktion kann entweder als Toptransaktion Unteraufträge an andere Transaktionen vergeben oder als Multitransaktion mit anderen Multitransaktionen kooperieren. Es ist nicht möglich, daß eine Transaktion sowohl Unteraufträge vergibt als auch mit anderen Transaktionen kooperiert. Auftragnehmer sind immer Toptransaktionen und können deshalb in keinem Fall kooperieren.
Im DOM Transaktionskonzept ist die Hauptintention von Multitransaktionen aufgrund dieser Probleme nicht die Kooperation, sondern die Erhöhung der Nebenläufigkeit bei langen Transaktionen durch frühzeitige Freigabe von Objektänderungen. Außerdem erleichtern Multitransaktionen wie in [Buchmann et al. 1992] beschrieben die Einbindung externer Datenbanken, deren Transaktionssteuerung nicht komplett von DOM übernommen werden kann.
Das DOM Transaktionsmodell zeigt ein grundsätzliches Problem, das auftritt, wenn zur Integration von Auftrags- und Kooperationsprinzip versucht wird, geschlossen und offen geschachtelte Transaktionen miteinander zu kombinieren:
Geschlossen und offen geschachtelte Transaktionen sind zwei Konzepte, die sich sowohl in ihrer Art der Nebenläufigkeitskontrolle als auch in der Art der Fehlerbehandlung unterscheiden. Auf der anderen Seite trennen beide Konzepte in ihren Mechanismen aber nicht zwischen Fehlerbehandlung und Nebenläufigkeitskontrolle. So funktioniert die Fehlerbehandlung der geschlossen geschachtelten Transaktionen, die eine Schadensausbreitung außerhalb des Aktionsbaums nicht betrachtet, nur deshalb, weil seitens der Nebenläufigkeitskontrolle die Isolation durchgesetzt wird. Die Aufgabe der Isolation hängt bei den offen geschachtelten Transaktionen direkt mit der Fehlerbehandlung auf der Grundlage der kompensierenden Transaktionen zusammen.
Auftrags- und Kooperationsprinzip sind Anforderungen, die nur die Nebenläufigkeitskontrolle betreffen. Bei der Integration dieser Prinzipien geht es also darum, zwei verschiedene Nebenläufigkeitskonzepte zu kombinieren. Das zugrundeliegende Konzept zur Fehlerbehandlung sollte von der Integration gar nicht betroffen sein und statt dessen unabhängig von der jeweiligen Nebenläufigkeitskontrolle die Fehler-Atomarität durchsetzen. Genau dieses ist aber bei der Integration der beiden geschachtelten Transaktionskonzepte nicht möglich. Daher kann kein auf offen geschachtelten Transaktionen basierendes Konzept ohne kompensierende Transaktionen auskommen, die den Anwendungsbereich des Konzepts wie oben gezeigt stark einschränken.
Ein anderer Ansatz zur Integration des Auftrags- und des Kooperationsprinzips wurde mit dem CONCORD Modell (,,Controlling CoopeRatation in Design Environments``) in [Ritter et al. 1993] und [Ritter et al. 1994] vorgestellt. CONCORD wurde zur Systemunterstützung von CAD Anwendungen in Arbeitsgruppen entwickelt, wobei die Schwerpunkte sowohl auf der Kooperation von Benutzern als auch auf der Delegation von Unteraufträgen liegen.
Das Konzept basiert auf den sogenannten Design Activities. Diese modellieren die Arbeitsabläufe, die zur Erledigung eines Auftrags nötig sind und haben eine ähnliche Struktur wie die in Abschnitt 2.4.2 vorgestellten ConTracts: Eine Design Activity besteht aus einem Skript zur Ausführung von Komponenten, den DOPs (Design Operations). Die DOPs sind wie die Schritte der ConTracts ACID-Transaktionen. Im Gegensatz zu ConTracts sind Design Activities aber keine Transaktionen, d. h. für sie wird weder Fehler-Atomarität noch Isolation oder Serialisierbarkeit zwingend gefordert. Allerdings stellt das System Mechanismen zur Verfügung, mit denen alle Berechnungen einer Design Activity zurückgesetzt oder Zwischenergebnisse von DOPs vor Zugriff von außen geschützt werden können.
CONCORD arbeitet mit einem versionierten Objektsystem. Zu Beginn einer Design Activity werden lokale Versionen der zu bearbeitenden Objekte angelegt. Jede DOP kann Objekte ändern und legt dadurch neue lokale Versionen dieser Objekte an. Wenn eine Design Activity erfolgreich endet, werden die letzten Objektversionen in den globalen Objektspeicher zurückgeschrieben. Dieses Zurückschreiben findet in der Regel aber nicht ,,blind`` statt, sondern die Design Activity bildet in einer sogenannten Konfigurierung aus der aktuellen globalen und der lokalen Version eine neue globale Version, wobei der Programmierer der Design Activity dafür verantwortlich ist, daß die Konsistenz des globalen Objektspeichers erhalten bleibt. Alle lokalen Objektversionen bilden den Scope, also die Menge der zugreifbaren Objekte einer Design Activity.
Eine Design Activity enthält neben dem Ausführungsskript der DOPs und den lokalen Objektversionen noch eine weitere Information: Mit einer Designspezifikation wird das Ziel einer Design Activity beschrieben. Sobald diese Spezifikation erfüllt ist, hat die Design Activity ihre Aufgabe erfüllt. Außerdem kann anhand einer Bewertungsfunktion jederzeit bestimmt werden, zu welchem Grad diese Spezifikation erfüllt ist.
Zwischen Design Activities können drei Typen von Beziehungen bestehen:
Der Auftraggeber erstellt für den Auftragnehmer eine Designspezifikation und kann ihm als initiale Objektversion Kopien einiger Objekte aus seinem eigenen Scope übergeben. Nach dem Ende des Auftragnehmers muß der Auftraggeber aus den endgültigen Objektversionen des Auftragnehmers und seinen eigenen aktuellen Versionen in einer Konfigurierungsphase einen neuen Objektzustand erzeugen.
Bei einem Abbruch einer DOP werden systemseitig alle ihre Änderungen zurückgesetzt, da es sich bei DOPs um normale ACID-Transaktionen handelt. (Es gibt auch die Möglichkeit Zwischenstände einer DOP vor Systemausfällen mittels Checkpointing zu schützen. Darauf wird hier aber nicht weiter eingegangen.) Schon beendete DOPs oder auch ganze Design Activities können zurückgesetzt werden, indem alle Objektversionen gelöscht werden, die von zurückgesetzten DOPs erzeugt wurden. Normalerweise kann dieses Zurücksetzen lokal durchgeführt werden, da alle Objektänderungen in lokalen Versionen durchgeführt wurden und deshalb keine Schadensausbreitung stattgefunden haben kann. Allerdings gibt es zwei Ausnahmen: Eine Schadensausbreitung kann entlang der Delegation- und der Usage-Abhängigkeiten stattgefunden haben. In diesem Fall informiert das System die abhängigen Design Activities von der Ungültigkeit der Objektversionen, so daß diese dann entscheiden können, wie sie darauf reagieren. Die abhängige Design Activity kann zum Beispiel als Reaktion selbst abbrechen, einzelne DOPs zurücksetzen oder auch ihre Arbeit fortsetzen.
Die Fehler-Atomarität wird also solange garantiert, wie von einer Design Activity keine Delegation- oder Usage-Abhängigkeiten abgehen. Falls dies aber der Fall ist, kann die abhängige Design Activity entscheiden, inwieweit ein ausgebreiteter Fehler zurückgesetzt wird.
Eine weitere wichtige Eigenschaft aus dem Bereich der Fehlerbehandlung ist die sogenannte Commit-Korrektheit, die im Rahmen der dynamischen Aktionen bei [Nett, Mock 1995] definiert wurde. Diese Eigenschaft besagt, daß Änderungen von Transaktionen, die sich im Zustand committed befinden, unter keinen Umständen mehr zurückgesetzt werden müssen. Zum einen schließt das die ACID-Eigenschaft der Permanenz ein und zum anderen dürfen die geänderten Objektzustände auch nicht mehr aufgrund einer Schadensausbreitung zurückgesetzt werden müssen. Auf der Ebene der DOPs ist die Commit-Korrektheit nicht gewährleistet, da bei einem Abbruch der Design Activity die committeten Objektzustände durch die Invalidierung dieser Objektversion zurückgesetzt werden können. Dies führt allerdings zu keinen Problemen, da diese Zwischenversionen ohnehin nur lokal sichtbar waren und das System eventuelle Delegation- oder Usage-Beziehungen registriert und die abhängigen Design Activities informiert.
Globale Objektversionen, die aus einer Konfigurierung als Endergebnisse einer Design Activity entstanden sind, können grundsätzlich nicht mehr zurückgesetzt werden. Daher besteht nie die Gefahr, daß sich eine Design Activity unbeabsichtigt von einer anderen noch nicht beendeten Design Activity abhängig macht. Abhängigkeiten können nur durch gezielt eingegangene Delegation- oder Usage-Beziehungen entstehen. Da die globalen Objektversionen nicht mehr zurückgesetzt werden können, kann die Konsistenz der globalen Objektversionen nur dann gewährleistet werden, wenn jede Design Activity ihre Ergebnisse erst dann durch Konfigurierung in den globalen Objektspeicher zurückschreibt, wenn sie von keiner anderen aktiven Design Activity mehr abhängt. Dies wird aber nicht vom System garantiert, sondern jede Design Activity ist selbst für die Überwachung der Abhängigkeiten verantwortlich. Falls eine Design Activity ihre Ergebnisse ,,zu früh`` zurückschreibt, riskiert sie einen inkonsistenten globalen Objektzustand, falls eine Design Activity, von der sie abhängt, anschließend noch abbricht. Die Commit-Korrektheit wird für Design Activities also nicht garantiert.
Grundsätzlich ist systemseitige Nebenläufigkeitskontrolle nur in einem sehr geringen Umfang notwendig, da aufgrund der Versionierung jede DOP auf unterschiedlichen Objekten, bzw. genauer auf unterschiedlichen Versionen desselben Objekts arbeitet. Lediglich beim Erstellen einer initialen lokalen Version und bei der Konfigurierung müssen globale Objekte gesperrt werden. Das lokale Halten von Objektversionen garantiert auch eine Isolation der Design Activities, die nur dann aufgebrochen werden kann, wenn eine Design Activity bewußt eine Delegation- oder Usage-Abhängigkeit aufbaut. Mehrere Design Activities können nebenläufig dieselben Objekte bearbeiten, indem jede Design Activity eine lokale Version dieses Objekt erstellt und dieses bearbeitet. Es können auch sogenannte Ableitungssperren erworben werden. Diese verhindern, daß andere Design Activities nebenläufig lokale Versionen der Objekte erstellen und garantieren somit eine ausschließliche Bearbeitung eines Objekts durch eine einzige Design Activity.
Diese einfache Nebenläufigkeitskontrolle beinhaltet allerdings die Notwendigkeit von Konfigurierungen, also der Zusammenführung unterschiedlicher Versionen. Konfigurierungsprozeduren können in der Regel nicht systemseitig vorgegeben werden, sondern müssen vom Applikationsprogrammierer zur Verfügung gestellt oder vom Benutzer interaktiv durchgeführt werden. Ein Großteil der Nebenläufigkeitskontrolle wird im CONCORD Modell also nicht systemseitig gelöst, sondern durch die Konfigurierung in die Hand des Anwenders gelegt. Konfigurierungen, die die Konsistenz der globalen Objekte erhalten und zum Beispiel auch Nebenläufigkeitsanomalien ausschließen, sind im allgemeinen aber nicht trivial durchzuführen.
Sowohl das Auftrags- als auch das Kooperationsprinzip werden im CONCORD Modell realisiert. Eine Delegation-Abhängigkeit zwischen zwei Design Activities entspricht einer Auftraggeber-Auftragnehmer-Beziehung. Dabei werden Objektänderungen, also neue Versionen, des Auftragnehmers bei dessen Ende nur für den Auftraggeber sichtbar, wie es das Auftragsprinzip fordert. Das Kooperationsprinzip wird über die Usage-Beziehung realisiert. Usage-Beziehungen können zwischen beliebigen Design Activities aufgebaut werden und erlauben den vor anderen Design Activities geschützten Informationsfluß in eine Richtung. Beidseitiger Informationsfluß ist möglich, indem eine zweite Usage-Beziehung in Gegenrichtung aufgebaut wird.
Das CONCORD Modell realisiert zwar das Auftrags- und das Kooperationsprinzip, allerdings macht das zugrundeliegende versionierte Objektsystem dieses Konzept für viele Anwendungsbereiche nur eingeschränkt geeignet: Entscheidende Teile der Nebenläufigkeitskontrolle werden nicht vom System gelöst, sondern durch die notwendige Konfigurierung der Applikation oder dem Anwender überlassen. Bei nebenläufiger Objektbearbeitung kann die Konfigurierung schnell so komplex werden, daß sie von einer programmierten Prozedur nicht geleistet werden kann, sondern von einem Anwender manuell durchgeführt werden muß. Auch liegt es in der Verantwortung des Anwenders, daß eine Konfigurierung erst dann durchgeführt wird, wenn keine Gefahr mehr besteht, daß die Objektzustände aufgrund von Abbrüchen anderer Design Activities zurückgesetzt werden müssen. Der einfache Mechanismus zur Fehlerbehandlung durch Reaktivierung alter Objektversionen wird nur dadurch möglich, daß der Anwender durch die Konfigurierung im Bereich der Nebenläufigkeitskontrolle einen erheblichen Aufwand leistet. Wie bei anderen Transaktionsmodellen zeigen sich auch hier die Nachteile einer fehlenden Orthogonalität von Fehlerbehandlung und Nebenläufigkeitskontrolle.
CONCORD erfordert zur Konsistenz-Erhaltung der Objekte oft Eingriffe durch den Benutzer, die in der Regel so komplex sind und soviel applikationsspezifisches Wissen benötigen, daß sie nicht vom Computer übernommen werden können. Daher eignet sich CONCORD eher für stark interaktive Arbeitsvorgänge einer beschränkten Anzahl Benutzer, aber nicht für umfangreiche verteilte Systeme, in denen die Konsistenz der Objekte in großem Maße durch die Systemverwaltung sichergestellt werden soll. Für ein sinnvolles und effektives Arbeiten mit einem solchen System müssen die Anforderungen bezüglich der Konsistenzerhaltung an den Anwender so gering wie möglich gehalten werden.