Ein Nachrichtenfluss kann aus folgenden Bestandteilen bestehen:
Im Folgenden wird eine typische Folge von Ereignissen bei der Verarbeitung einer Nachricht durch einen Nachrichtenfluss beschrieben:
Diese Folge von Ereignissen unterscheidet nicht zwischen dem Zugreifen auf Tabellen und dem Schreiben von Ausgabenachrichten. Obwohl ein Fluss oft irgendeine Art von Ausgabenachricht erstellt, gibt es keine wirkliche Unterscheidung zwischen diesem Vorgang und dem Aktualisieren einer Datenbanktabelle. In beiden Fällen ändert sich der Status der Daten im System.
=====x=========x===x=======x=============x====x===== 1 2 3 4 5 6
Die Linie stellt die Daten im System im Zeitverlauf dar. Beim Zeitpunkt 1 kommt eine Nachricht an und wird aus der Eingabewarteschlange genommen. Zum Zeitpunkt 2, 3, 4 und 5 werden Daten zur Aktualisierung von Datenbanktabellen verwendet, oder sie werden in Warteschlangen geschrieben. Änderungen des Status der Daten werden im Diagramm durch das Symbol x dargestellt. Zum Zeitpunkt 6 werden die Ausgabenachrichten gesendet, und das System ist inaktiv. Zwischen diesen Ereignissen wird der Status der Daten nicht verändert. Dies wird im Diagramm durch das Symbol = gekennzeichnet.
Bei einem Ausfall (z. B. ein Stromausfall bei dem Computer, auf dem der Broker ausgeführt wird) werden die vor dem Ausfall am Status von Tabellen und Warteschlangen vorgenommenen Änderungen noch ausgeführt, während die danach vorgenommenen Änderungen nicht ausgeführt werden. 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 aus dem Girokonto entnommen, aber nicht dem Hypothekenkonto hinzugefügt.
-----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. Beim Zeitpunkt 1 kommt eine Nachricht an und wird aus der Eingabewarteschlange genommen. Vor Zeitpunkt 1 sind keine zusätzlichen Daten im System vorhanden. Dies wird im Diagramm durch das Symbol - gekennzeichnet. Nach Zeitpunkt 1 gibt der Status an, dass eine Nachricht aus der Warteschlange genommen wurde, so dass sie, falls erforderlich, auch wieder dorthin zurück eingereiht werden kann. Zum Zeitpunkt 2, 3, 4 und 5 werden Daten zur Aktualisierung von Datenbanktabellen verwendet, oder sie werden in Warteschlangen geschrieben. Der Status der zusätzlichen Daten ändert sich erneut, so dass Sie die Änderungen an Tabellen und Warteschlangen bei Bedarf rückgängig machen können. Zum Zeitpunkt 6 werden die Ausgabenachrichten gesendet, das System ist inaktiv, und es sind auch keine zusätzlichen Daten mehr im System vorhanden. Zwischen diesen Ereignissen wird der Status der zusätzlichen Daten nicht verändert, was durch das Symbol = gekennzeichnet wird. Tritt zwischen Zeitpunkt 1 und Zeitpunkt 6 eine Störung auf, wird der ursprüngliche Zustand der Systemdaten mit Hilfe der zusätzlichen Daten wiederhergestellt, so dass keine Daten in die Ausgabewarteschlangen geschrieben wurden, keine Tabellen aktualisiert wurden und die Eingabenachricht nicht aus der Eingabewarteschlange genommen wurde. 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).
Die oben beschriebene Betriebsart wird koordinierter Transaktionsmodus genannt. Das erfolgreiche Abschließen einer Transaktion wird als Festschreiben (COMMIT-Operation) bezeichnet. Das nicht erfolgreiche Beenden wird als Zurücksetzen (ROLLBACK-Operation) bezeichnet.
Hauptmerkmal des koordinierten Transaktionsmodus ist, dass entweder alle aus einer Eingabenachricht resultierenden Änderungen an Warteschlangen und Tabellen oder gar keine Änderungen vorgenommen werden, und zwar unabhängig von Ort oder Zeitpunkt des Ausfalls. Dieses Verhalten ist jedoch nicht immer angemessen, wie die folgenden Beispiele zeigen:
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. Zum Zeitpunkt 3 wird eine Aktualisierung einer Tabelle oder Warteschlange vorgenommen. Eine weitere Aktualisierung findet an Zeitpunkt 6 statt. Bei Zeitpunkt 7 entscheidet der Nachrichtenfluss, dass alle Änderungen, die unter der externen Transaktion vorgenommen werden müssen, abgeschlossen sind, und er schreibt die Änderungen fest.
Falls im Nachrichtenfluss vor Zeitpunkt 7 ein Fehler auftreten würde, bliebe der Systemstatus unverändert, weil beide Transaktionen zurückgesetzt würden. Tritt ein Fehler nach Zeitpunkt 7, aber vor Zeitpunkt 9 auf, wurde die externe Transaktion bereits festgeschrieben. Die Haupttransaktion hingegen wird zurückgesetzt. Wenn bis Zeitpunkt 9 kein Fehler auftritt, werden beide Transaktionen festgeschrieben.
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 auch an unterschiedlichen Tabellen weitere Änderungen vornehmen und diese wiederum festschreiben oder zurücksetzen.
Jede von Ihnen verwendete Datenbank hat ihre eigene externe Transaktion. Wenn folglich der Nachrichtenfluss Tabellen aktualisiert, die unterschiedlichen Datenbankinstanzen angehören (unterschiedliche Datenquellennamen), wird für jede Datenbank eine eigene externe Transaktion ausgeführt. Sie müssen diese Transaktionen einzeln festschreiben oder zurücksetzen. Aktualisierungen, die nach abgeschlossenem Arbeitsgang (Zeitpunkt 9 im obigen 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.
Einige Datenbanktypen (z. B. DB2 unter AIX) unterstützen keine gleichzeitigen koordinierten und unkoordinierten Transaktionen in derselben Datenbankinstanz. In diesen Fällen müssen Sie separate Datenbankinstanzen erstellen. Konfigurieren Sie eine Datenbankinstanz für koordinierte und eine andere für unkoordinierte Transaktionen.
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.
Nicht alle Warteschlangensysteme verfügen über die zuvor beschriebenen Datenbankfunktionen. Bei WebSphere MQ besitzt jede einzelne unkoordinierte Lese- oder Schreiboperation für eine Warteschlange eine implizierte COMMIT-Aktion, so dass Sie nicht zwei Nachrichten einreihen können und anschließend entscheiden können, ob sie beide festschreiben oder zurücksetzen. Deshalb können die Anweisungen COMMIT und ROLLBACK nur in Datenbanken ausgeführt werden.
In der obigen Beschreibung werden Nachrichtenflüsse erwähnt, Knoten jedoch nicht. Die Aufteilung eines Nachrichtenflusses in Knoten wirkt sich nicht auf Transaktionen aus. Für Datenbankoperationen kann jede Anzahl von Knoten uneingeschränkt Aktualisierungen an der Haupttransaktion und an einer beliebigen Menge von externen Transaktionen vornehmen.
Wenn alle Datenbankaktualisierungen in externen Transaktionen vorgenommen werden, können Sie das Attribut Koordinierte Transaktion des Nachrichtenflusses auf no setzen, um alle Tabellenverweise außerhalb der Haupttransaktion zu beeinflussen. Auf diese Weise müssen Sie das Attribut nicht für jede Datenbankoperation angeben.