6.6 Der Transaktionsmechanismus

  Aktionen, die von den Agenten ausgeführt werden, sind im JMAPI-Kommunikationsmodell die Folge von Manipulationsoperationen an Managed Objects.

Im Gegensatz zu reinen Leseoperationen auf MOs können Änderungen, die den Zustand einzelner MOs betreffen, bzw. neue MO-Instanzen anlegen oder vorhandene MOs löschen, nur innerhalb eines sog. Update-Kontexts erfolgen. Dieser faßt eine Reihe von Änderungsaktionen zu einer Transaktion mit den aus dem Datenbankbereich bekannten ACID-Eigenschaften zusammen. Obwohl ein erfolgreich abgeschlossener Update-Kontext Änderungen in der Datenbank zur Folge hat, ist er nicht mit der darunterliegenden Datenbanktransaktion zu verwechseln.

Sind die Agenten, die von Änderungen einer Reihe von MOs innerhalb einer Transaktion betroffen sind, als in Java implementierte Agent Objects realisiert, die durch eine Agent Object Factory verwaltet werden (vgl. Abschnitt 6.1), so bietet JMAPI die Möglichkeit, die Änderungsaktionen auf den Agenten ebenfalls in den Tranksaktionsmechanismus mit einzubeziehen.

Zur Verdeutlichung der Zusammenhänge soll im folgenden exemplarisch vorgeführt werden, wie ein Client Modifikationen an Managed Objects vornimmt, die als Folge Aktionen von Agenten nach sich ziehen. Abbildungen 6.5 und 6.6 zeigen schematisch die zugehörigen Abläufe.

  

Abbildung 6.5: Ablauf eines Updates, Teil 1

  

Abbildung 6.6: Ablauf eines Updates, Teil 2

Zunächst öffnet der Client mit dem Aufruf beginUpdate auf einem Session-Objekt einen neuen Update-Kontext. Jetzt kann er mittels der get- und set-Methoden, die die in Betracht kommenden Managed Objects für jedes ihrer Attribute bereitstellen, Modifikationen an einzelnen Managed Objects vornehmen (Schritt 2). Hat der Client die gewünschten Veränderungen am Zustand der MOs vorgenommen, schließt er mittels des Aufrufs commitUpdate die Transaktion ab (Schritt 3). An dieser Stelle werden von JMAPI automatisch die performModifyActions-Methoden eines jeden Objekts, das verändert wurde, aufgerufen (siehe hierzu auch Abschnitt 3.2). Die Standard-Implementierung dieser Methoden ist leer. Der Anwendungsentwickler kann durch Umdefinieren dieser Methoden Aktionen auf den Agenten ausführen lassen, die dann bei jeder Modifikation des MO-Zustandes zum Einsatz kommen (Schritt 4). Als nächstes wird versucht, die Änderungen in der Datenbank zu speichern (Schritt 5 in Abbildung 6.6). Tritt hierbei ein Fehler auf, so wird ein Rollback der Transaktion veranlaßt. Da es möglich ist, daß auf den Agenten im Rahmen der performModifyActions-Ausführung Änderungen vollzogen wurden (vgl. Schritt 4), muß in diesem Fall dafür Sorge getragen werden, diese Änderungen rückgängig zu machen. Zu diesem Zweck wird beim Aufruf von performModifyActions dem Agenten in einer für den Benutzer transparenten Weise ein CommitAndRollback Objekt übergeben. Der Agent kann mit Hilfe dieses Objekts beim Manager zwei Callback-Funktionen registrieren, jeweils für die beiden Fälle einer erfolgreichen oder fehlgeschlagenen Datenbanktransaktion. Im Falle eines Rollbacks wird dann die Rollback-Callback Funktion ausgeführt (Schritt 6a in Abbildung 6.6), im Fall eines Commits die Commit-Callback-Funktion (Schritt 6b).

Wie aus diesen Ausführungen ersichtlich ist, beinhaltet jede Modifikation eines Agenten drei mögliche Phasen. Die Setup-Phase, in obiger Erläuterung das Aufrufen von Methoden auf dem Agenten von der performModifyActions Methode aus (vgl. Schritt 4), kann bereits Änderungen auf dem Agenten durchführen. Je nachdem, ob das Schreiben der modifizierten Attributwerte des Managed Objects in die Datenbank erfolgreich war oder nicht, wird im Anschluß hieran die Commit-Phase oder die Rollback-Phase (vgl. Schritt 6a bzw. 6b) eingeleitet.

Im Hinblick auf die Implementierung von Aktionen auf den Agenten ergeben sich somit verschiedene Möglichkeiten. Beispielsweise könnte während der Setup-Phase nichts gemacht werden und alle Änderungen innerhalb der Commit-Phase erfolgen. Ein Rollback wäre dann nicht notwendig. Alternativ könnten auch alle Änderungen während der Setup-Phase vollzogen werden, die Commit-Phase wäre dann leer und die Rollback-Phase müßte die Aktionen der Setup-Phase rückgängig machen.

Vorangehend wurde der Ablauf von Modifikationsoperationen auf eine Reihe von Managed Objects an einem Beispiel geschildert. Sollen MO-Instanzen gelöscht werden, oder neue Instanzen angelegt werden, geschieht dies im wesentlichen auf dieselbe Weise. Nach Abschluß des Update-Kontexts mit commitUpdate werden in diesen Fällen die Methoden performDeleteActions bzw. performNewActions ausgeführt.

Ein Rollback wird nicht nur durch eine gescheiterte Datenbanktransaktion ausgelöst, sondern kann auch von einem Client mittels Aufruf der Methode abandonUpdate ausgelöst werden.