WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Transaktionsorientiertes Modell

Das transaktionsorientierte Modell beschreibt, wie Sie Transaktionen in Nachrichtenflüssen verwenden können, um bestimmte Aufgaben auszuführen und bestimmte Ergebnisse zu erzielen.

Ein Nachrichtenfluss besteht aus folgenden Komponenten:

Die folgenden Schritte entsprechen einer typischen Folge von Ereignissen in der Nachrichtenflusstransaktion:

  1. Es wird eine Nachricht aus der Eingabequelle abgerufen, z. B. aus einer Warteschlange.
  2. Es werden Daten aus einer oder mehreren externen Ressourcen, z. B. einer Datenbank, gelesen oder in die Ressourcen geschrieben.
  3. Es wird eine Nachricht an ein Ausgabeziel gesendet, z. B. an eine Warteschlange.
  4. Das System wird in den Wartemodus versetzt und wartet auf die nächste Eingabenachricht.

Während dieser Ereignisfolge ändert sich der Status der Daten im System unabhängig davon, auf wie viele externe Ressourcen der Nachrichtenfluss zugreift und ob er eine Ausgabenachricht generiert.

Sehen Sie sich das folgende Beispiel an:
	-----x---------x---x-------x-------------x----x-----
	     	     1         2   3       4             5    6

Die Linie stellt die Daten im System im Zeitverlauf dar. Bei 1 kommt eine Nachricht an und wird aus der Eingabewarteschlange abgerufen. Bei 2, 3, 4 und 5 werden externe Ressourcen anhand der Daten aktualisiert, z. B. eine Datenbanktabelle oder eine Ausgabewarteschlange. Änderungen des Status der Daten werden im Diagramm durch das Symbol x dargestellt. Bei 6 werden die Ausgabenachrichten gesendet, und das System ist inaktiv. Zwischen diesen Ereignissen ändert sich der Status der Daten nicht. Er wird im Diagramm durch das Symbol = gekennzeichnet.

Bei einer Störung auf dem System (z. B. einem Stromausfall des Computers, auf dem der Broker ausgeführt wird) werden die vor der Störung am Status von externen Ressourcen vorgenommenen Änderungen noch implementiert, die danach vorgenommenen Änderungen jedoch nicht mehr. Diese Situation ist in bestimmten Fällen nicht akzeptabel. Beispiel: Wenn bei einer Zahlung von einem Girokonto an ein Hypothekenkonto ein Systemausfall auftritt, wird das Geld möglicherweise vom Girokonto abgebucht, aber nicht dem Hypothekenkonto gutgeschrieben.

Transaktionen

Um das oben beschriebene Problem zu vermeiden, verfügen der Broker und die externen Ressourcenmanager, mit denen er zusammenarbeitet, über ein transaktionsorientiertes Modell. Der Broker startet eine Transaktion, wenn Daten bei einem Empfangsknoten im Nachrichtenfluss eingehen, und beendet sie, sobald die Verarbeitung dieser Daten abgeschlossen ist. Weitere Informationen zu Nachrichtenflusstransaktionen finden Sie im Abschnitt Nachrichtenflusstransaktionen.

Bei fortlaufender Verarbeitung in einer Transaktion werden zusätzliche Daten aufgezeichnet, die im Falle einer Störung die Wiederherstellung des ursprünglichen Status ermöglichen. Der Status dieser zusätzlichen Daten wird im nachfolgenden Diagramm dargestellt:
	-----x=========x===x=======x=============x====x-----
	     	     1         2   3       4             5    6

Die Linie im Diagramm stellt die zusätzlichen Daten im System im Zeitverlauf dar. Bei 1 kommen Eingabedaten aus der Eingabequelle an, z. B. einer Warteschlange. Vor Zeitpunkt 1 sind keine zusätzlichen Daten im System vorhanden. Dieser Status wird im Diagramm durch das Symbol - gekennzeichnet. Nach Zeitpunkt 1 gibt der Status an, dass Daten von der Eingabequelle empfangen wurden, sodass sie, falls erforderlich, wiederhergestellt werden können. Bei 2, 3, 4 und 5 werden externe Ressourcen anhand der Daten aktualisiert, z. B. Datenbanken oder Dateien. Erneut ändert sich der Status der zusätzlichen Daten, sodass die Änderungen an den externen Ressourcen bei Bedarf rückgängig gemacht werden können. Bei 6 werden die Ausgabenachrichten gesendet, das System ist inaktiv und im System sind keine zusätzlichen Daten mehr vorhanden.

Zwischen diesen Ereignissen wird der Status der zusätzlichen Daten nicht verändert. Der Status wird durch das Symbol = gekennzeichnet. Wenn zwischen den Zeitpunkten 1 und 6 eine Störung auftritt, wird der ursprüngliche Status der Daten in den externen Ressourcen anhand der zusätzlichen Daten wiederhergestellt. Das heißt, tatsächlich wurden keine Ausgabedaten in das Ausgabeziel geschrieben, keine der externen Ressourcen aktualisiert und die Eingabedaten nicht aus der Eingabequelle empfangen. Treten keine Störungen auf, werden die Änderungen bei Zeitpunkt 6 dauerhaft übernommen (und können nach einer anschließenden Störung nicht rückgängig gemacht werden).

Dieser Betriebsmodus wird als koordinierter Transaktionsmodus bezeichnet. Das erfolgreiche Abschließen einer Transaktion wird als Festschreiben (COMMIT-Operation) bezeichnet. Das nicht erfolgreiche Beenden wird als Zurücksetzen (ROLLBACK-Operation) bezeichnet.

Nicht koordinierte externe Transaktionen

Hauptmerkmal des koordinierten Transaktionsmodus ist, dass entweder alle aus einer Eingabenachricht resultierenden Änderungen an externen Ressourcen oder gar keine Änderungen vorgenommen werden, und zwar unabhängig von Ort oder Zeitpunkt der Störung. Dieses Verhalten ist jedoch nicht immer angemessen, wie die folgenden Beispiele zeigen:

Falls Ihre Nachrichtenflüsse Anforderungen wie diese erfüllen müssen, können Sie Nachrichtenflüsse konfigurieren, durch die eine oder mehrere Ressourcen in einer separaten bzw. externen Transaktion geändert werden. Dieser Transaktionstyp wird nicht von allen Ressourcenmanagern unterstützt.

Bei manchen Ressourcen wird eine externe Transaktion automatisch gestartet. So startet beispielsweise jede Datenbankverbindung eine für die betreffende Datenbank spezifische Transaktion. Alle in dieser Transaktion durchgeführten Aktualisierungen können dann festgeschrieben oder zurückgesetzt werden.

Das Verhalten einer externen Transaktion wird in folgendem Diagramm veranschaulicht:
MAIN -----x=========x===x=======x=============x====x-----
          1         2   4       5             8    9

1. AUX --------------x======x========x------
                      3      6        7

Die Zeile MAIN stellt die Haupttransaktion dar, die die zusätzlichen Daten enthält, die bei Bedarf zum Wiederherstellen des ursprünglichen Zustands erforderlich sind. Die Zeile 1. AUX stellt eine Transaktion einer externen Einheit dar. Bei 3 wird eine externe Ressource aktualisiert. Eine weitere Aktualisierung findet bei 6 statt. Bei 7 entscheidet der Nachrichtenfluss, dass alle Änderungen, die unter der externen Transaktion durchgeführt werden müssen, abgeschlossen sind, und er schreibt die Änderungen fest.

Falls im Nachrichtenfluss vor Zeitpunkt 7 eine Störung auftritt, bleibt der Systemstatus unverändert, weil beide Transaktionen zurückgesetzt werden. Tritt eine Störung nach Zeitpunkt 7, aber vor Zeitpunkt 9 auf, wurde die externe Transaktion bereits festgeschrieben. Die Haupttransaktion wird jedoch zurückgesetzt. Wenn bis Zeitpunkt 9 keine Störung auftritt, werden beide Transaktionen festgeschrieben.

Externe Datenbanktransaktionen

Sie können mehrere externe Transaktionen verwenden und eine Reihe von Aktualisierungen an Datenbanktabellen vornehmen, die festgeschrieben oder zurückgesetzt werden können. Anschließend können Sie an denselben oder an anderen Datenbanktabellen weitere Änderungen vornehmen und diese festschreiben oder zurücksetzen.

Jede von Ihnen verwendete Datenbank hat ihre eigene externe Transaktion. Wenn der Nachrichtenfluss Tabellen aktualisiert, die unterschiedlichen Datenbankinstanzen angehören (unterschiedliche Datenquellennamen), wird deshalb für jede Datenbank eine eigene externe Transaktion ausgeführt. Sie können diese Zusatztransaktionen optional einzeln festschreiben oder zurücksetzen. Aktualisierungen, die bei Abschluss des Nachrichtenflusses (Zeitpunkt 9 im vorangegangenen Beispiel) nicht festgeschrieben oder zurückgesetzt wurden, werden automatisch vom Broker festgeschrieben oder zurückgesetzt - je nachdem, ob die Verarbeitung erfolgreich war oder fehlgeschlagen ist.

Verwenden Sie die ESQL-Anweisungen COMMIT und ROLLBACK zum Festschreiben und Zurücksetzen externer Datenbanktransaktionen. Rufen Sie Operationen außerhalb der Haupttransaktion ab, indem Sie das Schlüsselwort UNCOORDINATED in den einzelnen Datenbankanweisungen (z. B. INSERT und UPDATE) angeben.

Externe Warteschlangentransaktionen

Nicht alle Warteschlangensysteme verfügen über die zuvor beschriebenen Datenbankfunktionen. Bei WebSphere MQ besitzt jede einzelne nicht koordinierte Lese- oder Schreiboperation für eine Warteschlange eine implizite Commitaktion. Deshalb können Sie nicht zwei Nachrichten einreihen und anschließend entscheiden, ob sie beide festschreiben oder beide zurücksetzen. Deshalb können die Anweisungen COMMIT und ROLLBACK nur in Datenbanken ausgeführt werden.

Knoten

In den vorangegangenen Abschnitten wurde auf Nachrichtenflüsse, nicht auf Knoten eingegangen. Die Einteilung eines Nachrichtenflusses in Knoten wirkt sich nicht auf Transaktionen aus. Bei Datenbankoperationen kann eine unbegrenzte Anzahl von Knoten uneingeschränkt Aktualisierungen an der Haupttransaktion und an einer unbegrenzten Anzahl externer Transaktionen vornehmen.

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:19:57


KonzeptthemaKonzeptthema | Version 8.0.0.5 | ac07010_