Einen Nachrichtenfluss kann man sich so vorstellen, dass er aus folgenden Bestandteilen besteht:
Die Ereignisse bei der Verarbeitung einer Nachricht durch einen Fluss treten in folgender Reihenfolge aus:
Diese Folge von Ereignissen unterscheidet nicht zwischen dem Zugreifen auf Tabellen und dem Schreiben von Ausgabenachrichten. Obwohl normalerweise von einem Fluss angenommen wird, dass er irgendeine Art von Ausgabenachricht erstellt, gibt es keine wirkliche Unterscheidung zwischen diesem Vorgang und dem Aktualisieren einer Datenbanktabelle. In beiden Fällen handelt es sich lediglich um eine Statusänderung 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 Datenbanktabellen aktualisiert oder es wird in Warteschlangen geschrieben. Diese Statusänderungen werden mit dem Symbol 'x' gekennzeichnet. Zuletzt werden zu Zeitpunkt 6 die Ausgabenachrichten gesendet und das System wird in den Wartemodus versetzt. Zwischen diesen Ereignissen wird der Status der Daten nicht verändert, was durch das Symbol '=' gekennzeichnet wird.
Nun soll bedacht werden, welche Auswirkung Ausfälle auf das System haben. Bei einem Ausfall (z. B. Unterbrechung des Netzanschlusses der Maschine, auf der 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. Eine solche Situation ist in keinem Fall akzeptabel (Beispiel: Eine Zahlung vom Girokonto an das Hypothekenkonto wurde zwar aus der Girokontotabelle genommen, aber nicht der Hypothekentabelle hinzugefügt.).
=====x=========x===x=======x=============x====x===== 1 2 3 4 5 6
Die Linie stellt die zusätzlichen Daten im System im Zeitverlauf dar. Beim Zeitpunkt 1 kommt eine Nachricht an und wird aus der Eingabewarteschlange genommen. Davor sind keine zusätzlichen Daten im System vorhanden, was durch das Symbol '-' gekennzeichnet wird. Nach diesem Zeitpunkt gibt der Status an, dass eine Nachricht aus einer Warteschlange genommen wurde, so dass sie, falls erforderlich, auch wieder dorthin zurück eingereiht werden kann. Zum Zeitpunkt 2, 3, 4 und 5 werden Datenbanktabellen aktualisiert oder es wird 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. Zuletzt werden zu Zeitpunkt 6 die Ausgabenachrichten gesendet und das System wird in den Wartemodus versetzt, 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 geändert 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.
Diese 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. (In Abschnitt XYZ finden Sie eine ausführliche Beschreibung dieser Operationen. Beachten Sie jedoch, dass dies keine Standardvorgänge sind und sie nicht von allen Datenbanken und Warteschlangensystemen unterstützt werden.)
Hauptmerkmal und Hauptvorteil eines 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. Er eignet sich jedoch nicht für alle Situationen gleichermaßen. Folgende zwei Beispiele belegen das:
MAIN -----x=========x===x=======x=============x====x----- 1 2 4 5 8 9 1. AUX --------------x======x========x------ 3 6 7
Die obere Zeile stellt die Haupttransaktion wie zuvor dar. Transaktion ist nur ein abstrakter Begriff für die zusätzlichen Daten, die bei Bedarf zum Wiederherstellen des ursprünglichen Zustands erforderlich sind. Die untere Zeile stellt eine Transaktion einer externen Einheit dar. Bei Zeitpunkt 3 wird eine Tabelle oder eine Warteschlange aktualisiert. Eine weitere Aktualisierung findet an Zeitpunkt 6 statt. Bei Zeitpunkt 7 entscheidet der Fluss, dass alle Änderungen, die unter der externen Transaktion vorgenommen werden müssen, abgeschlossen sind und schreibt die Änderungen fest.
Falls im Fluss vor Zeitpunkt 7 ein Fehler auftritt, 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 ohne Fehler festgeschrieben.
Sie haben die Möglichkeit, mehrere externe Transaktionen zu verwenden, und sind auch nicht allein auf das Festschreiben der externen Transaktionen beschränkt. Es können zahlreiche Aktualisierungen an den Datenbanktabellen vorgenommen werden, die jeweils entweder festgeschrieben oder zurückgesetzt werden können. Anschließend können Sie an denselben oder auch an unterschiedlichen Tabellen Änderungen vornehmen und diese wiederum festschreiben oder zurücksetzen.
Jede von Ihnen verwendete Datenbank hat ihre eigene externe Transaktion. Wenn folglich der Fluss Tabellen aktualisiert, die unterschiedlichen Datenbankinstanzen angehören (d. h. unterschiedliche Datenquellnamen), wird für jede Datenbank eine eigene externe Transaktion ausgeführt. Diese müssen einzeln festgeschrieben oder zurückgesetzt werden. Aktualisierungen, die nach abgeschlossenem Arbeitsgang (Zeitpunkt 9) nicht festgeschrieben oder zurückgesetzt wurden, werden automatisch vom Broker festgeschrieben oder zurückgesetzt - je nachdem, ob die Verarbeitung erfolgreich war oder fehlgeschlagen ist (d. h. ob eine Ausnahme den Empfangsknoten erreicht oder nicht).
Einige Datenbanktypen (z. B. DB2 unter AIX) unterstützen keine gleichzeitigen koordinierten und unkoordinierten Transaktionen in derselben Datenbankinstanz. In diesen Fällen müssen separate Datenbankinstanzen erstellt werden. Konfigurieren Sie eine Datenbankinstanz für koordinierte und eine andere für unkoordinierte Transaktionen.
Verwenden Sie zum Festschreiben oder Zurücksetzen externer Datenbanktransaktionen die ESQL-Anweisungen COMMIT bzw. ROLLBACK. Operationen außerhalb der Haupttransaktion werden abgerufen, indem die Anweisung UNCOORDINATED in den jeweils verwendeten Datenbankanweisungen, wie z. B. INSERT und UPDATE, angegeben wird.
Nicht alle Warteschlangensysteme verfügen über dieselben Transaktionsfunktionen wie für Datenbanken zuvor beschrieben. Bei MQ besitzt jeder einzelne unkoordinierte Lese- oder Schreibvorgang eine implizierte COMMIT-Operation. Aus diesem Grund können Sie beispielsweise keine PUT-Operation für zwei Nachrichten ausführen und anschließend beide festschreiben oder beide zurücksetzen. Diese Einschränkung rührt von dem zu Grunde liegenden System her, das von WebSphere Message Broker nicht ausgeblendet werden kann. Deshalb können die Anweisungen COMMIT und ROLLBACK nur in Datenbanken ausgeführt werden.
In der bisherigen Beschreibung wurden nur Flüsse, nicht jedoch Knoten erwähnt. Wie ein Fluss in Knoten unterteilt ist, ist im Prinzip für eine Beschreibung von Transaktionen ohne Bedeutung. Jede Anzahl von Knoten kann uneingeschränkt Aktualisierungen an der Haupttransaktion und an einer beliebigen Menge von externen Transaktionen vornehmen. Was Sie tun, ist von Bedeutung, aber nicht wie Sie es tun. In der Praxis trifft diese Aussage jedoch nur auf Operationen an Datenbanken zu, weil andere Datenquellen (VSAM, Warteschlangen) einfach größere Einschränkungen des Leistungsspektrums aufweisen.
Ein Sonderfall, der erwähnt werden muss, liegt vor, wenn alle Datenbankaktualisierungen innerhalb externer Transaktionen ausgeführt werden. In diesem Fall kann das Attribut 'Koordinierte Transaktion' des Nachrichtenflusses auf 'Nein' gesetzt werden. Dadurch werden alle Tabellenverweise außerhalb der Haupttransaktion ausgeführt, ohne dass dies in jeder Datenbankoperation einzeln angegeben werden muss. Zudem werden auch die Abläufe unter Umständen beschleunigt.