Ein koordinierter Nachrichtenfluss wird innerhalb einer einzelnen Transaktion ausgeführt. Dies wird gestartet, wenn ein Empfangsknoten eine Nachricht empfängt und kann festgeschrieben oder zurückgesetzt werden, nachdem alle Verarbeitungsschritte abgeschlossen wurden. Sie können auch steuern, wie Datenbankfehler von dem Knoten verarbeitet werden, der mit der Datenbank interagiert.
Wenn die Aktionen eines Nachrichtenflusses global koordiniert werden
sollen (d. h., entweder muss die gesamte Verarbeitung erfolgreich sein, oder es wird keine
Verarbeitung abgeschlossen), müssen Sie sich vergewissern, dass diese Aktion von Ihrer
Konfiguration unterstützt wird. Weitere Informationen zur globalen Koordination von
Nachrichtenflusstransaktionen finden Sie unter
Das transaktionsorientierte Modell.
Das folgende Beispiel veranschaulicht den Einsatz von global koordinierten Transaktionen und zeigt, wie der Nachrichtenfluss jeweils anders reagiert, je nachdem, ob die Datenbankaktualisierungen koordiniert werden (Hauptnachrichtenfluss) oder nicht (Fehlernachrichtenfluss).
Sie können Beispiele nur anzeigen, wenn Sie das Information Center
verwenden, das im Message
Brokers Toolkit integriert ist.
Gehen Sie wie folgt vor, um einen Nachrichtenfluss für die globale
Koordination zu konfigurieren:
- Wechseln Sie im Message
Brokers Toolkit zur
Ansicht 'Brokeranwendungsentwicklung'.
- Öffnen Sie den Nachrichtenfluss, den Sie konfigurieren möchten.
- Legen Sie die Eigenschaft Transaktion für die folgenden Knoten fest, sofern sie im Nachrichtenfluss verwendet werden:
- Compute-Knoten
- Database-Knoten
- DataDelete-Knoten
- DataInsert-Knoten
- DataUpdate-Knoten
- Filter-Knoten
- Mapping-Knoten
- Warehouse-Knoten
Die Eigenschaft Transaktion kann auf die folgenden Werte gesetzt werden:
- Automatisch
- Alle vom Knoten ausgeführten Aktualisierungen, Löschungen und Ergänzungen werden festgeschrieben oder zurückgesetzt, wenn die Nachrichtenflussverarbeitung abgeschlossen ist. Wenn der Nachrichtenfluss erfolgreich abgeschlossen wird, werden alle Änderungen festgeschrieben. Falls der Nachrichtenfluss nicht erfolgreich abgeschlossen wird, werden alle Änderungen zurückgesetzt.
Wenn die gesamte Verarbeitung durch den Nachrichtenfluss koordiniert werden soll, müssen Sie diesen Wert auswählen.
- Festschreiben
- Die ausgeführte Aktion hängt von dem System ab, für das der Nachrichtenfluss implementiert wurde:
Wenn Sie im selben Nachrichtenfluss Knoten mit einer Transaktionalität des Typs
Automatisch und des Typs
Festschreiben kombinieren möchten und die
Knoten auf dieselbe externe Datenbank zugreifen, dann verwenden Sie separate ODBC-Verbindungen:
eine für die Knoten, die erst nach Abschluss des Nachrichtenflusses festgeschrieben werden sollen,
und eine für die Knoten, die sofort festgeschrieben werden sollen. Wenn Sie keine separaten ODBC-Verbindungen verwenden, schreiben die Knoten, die sofort festgeschrieben werden, auch alle Operationen fest, die von früheren Knoten des
Typs
Automatisch ausgeführt werden.
Anmerkung: Auf anderen Systemen als z/OS wird diese Betriebsart nicht in allen Fällen von relationalen Datenbanken unterstützt.
Wenn Sie mehrere ODBC-Verbindungen definieren, treten möglicherweise Probleme in Bezug auf Datenbanksperren auf. Insbesondere bedeutet dies Folgendes: Wenn ein Knoten mit der Transaktionalität Automatisch eine Operation wie beispielsweise INSERT oder UPDATE ausführt, die zu einer Sperre eines Datenbankobjekts (z. B. einer Tabelle) führt, und ein nachfolgender Knoten versucht, über eine andere ODBC-Verbindung auf dieses Datenbankobjekt zuzugreifen, tritt eine unendliche Sperre (gegenseitige Sperre) auf.
Der zweite Knoten wartet darauf, dass die Sperre des ersten Knotens freigegeben wird, aber der erste Knoten schreibt seine Operationen erst fest und gibt die Sperre frei, wenn der Nachrichtenfluss abgeschlossen ist; dies wird jedoch nie eintreten, da der zweite Knoten darauf wartet, dass die Datenbanksperre des ersten Knotens freigegeben wird.
Eine derartige Situation kann von keinen DBMS-Routinen zur automatischen Vermeidung von gegenseitigen Sperren entdeckt werden, da die beiden Operationen indirekt unter Verwendung des Brokers interagieren.
Diese Art des Sperrproblems kann auf zwei Arten vermieden werden:
- Entwerfen Sie Ihren Nachrichtenfluss so, dass nicht festgeschriebene (automatische) Operationen keine Datenbankobjekte sperren, auf die nachfolgende Operationen, die eine andere ODBC-Verbindung nutzen, zugreifen müssen.
- Konfigurieren Sie für Ihre Datenbank den Parameter für das Sperrzeitlimit so, dass ein Versuch zur Anforderung einer Sperre nach einer bestimmten Dauer fehlschlägt. Schlägt eine Datenbankoperation aufgrund des Zeitlimits für
Sperren fehl, wird eine Ausnahmebedingung ausgelöst, die der Broker wie gewohnt bearbeitet.
Die Produktdokumentation Ihrer Datenbank enthält Informationen darüber, welche Datenbankobjekte von bestimmten Operationen gesperrt werden, und wie der Parameter für das Sperrzeitlimit Ihrer Datenbank konfiguriert werden soll.
- Legen Sie die Eigenschaft Transaktionsmodus für die folgenden Knoten fest, sofern sie sich in diesem Nachrichtenfluss befinden:
- MQInput-Knoten
- MQOutput-Knoten
- MQReply-Knoten
- SCADAInput-Knoten
- JMSInput-Knoten
- JMSOutput-Knoten
Die folgende Tabelle zeigt eine Zusammenfassung der Aktionen,
die aufgrund bestimmter Einstellungen in den Eigenschaften für Eingabe- und Sendeknoten
ausgeführt wurden.
Nachrichtenpermanenz a |
Transaktionsmodus des Empfangsknotens |
Transaktionsmodus des MQOutput- oder MQReply-Knotens |
Nachrichtenfluss ist global koordiniert? |
Ja |
Ja |
Automatisch |
Ja |
Nein |
Ja |
Automatisch |
Ja |
Ja |
Nein |
Automatisch |
Nein |
Nein |
Nein |
Automatisch |
Nein |
Ja |
Automatisch |
Automatisch |
Ja |
Nein |
Automatisch |
Automatisch |
Nein |
Beliebig b |
Beliebig b |
Ja |
Ja |
Beliebig b |
Beliebig b |
Nein |
Nein |
Anmerkungen: - Die Permanenz ist nur für Nachrichten relevant, die über die Protokolle 'WebSphere MQ
Enterprise Transport', 'WebSphere MQ Mobile Transport' und 'WebSphere MQ
Telemetry Transport' empfangen werden.
- Der an dieser Stelle festgelegte Wert wird durch die Einstellung in der Eigenschaft des MQOutput- oder MQReply-Knotens überschrieben.
- Die Transaktionsmoduseinstellungen der JMSInput- und JMSOutput-Knoten werden anders als in der vorhergehenden Tabelle festgelegt. Weitere Informationen hierzu finden Sie unter JMSInput-Knoten und JMSOutput-Knoten.
Der Standardwert für jeden Empfangsknoten lautet Ja, was bedeutet, dass die eingehenden Nachrichten unter Synchronisationspunktsteuerung verarbeitet werden. Darüberhinaus werden Nachrichten, die an den Outputknoten gesendet werden, unter Synchronisationspunktsteuerung zugestellt. Sie können dieses Verhalten ändern, wenn es sich beim Sendeknoten um einen MQOutput- oder MQReply-Knoten handelt, die beide über die Eigenschaft Transaktionsmodus verfügen.
Wenn Sie die Eigenschaft Transaktionsmodus in einem Empfangsknoten auf Automatisch setzen, werden die eingehenden Nachrichten nur unter der Synchronisationspunktsteuerung verarbeitet , wenn sie als persistent definiert sind. An den MQOutput-Knoten gesendete Nachrichten werden unter Synchronisationspunktsteuerung zugestellt, es sei denn, Sie ändern im MQOutput-Knoten explizit die Eigenschaft Transaktionsmodus.
- Legen Sie die Eigenschaften Warnungen als Fehler behandeln und Ausnahme für Datenbankfehler ausgeben für jeden Knoten fest, der auf eine Datenbank zugreift, um anzugeben, wie dieser Knoten Datenbankwarnungen und -fehler behandeln soll. Ob Sie diese Eigenschaften auswählen und wie Sie die Fehlerterminals der Knoten verbinden, wirkt sich auch darauf aus, wie Datenbankaktualisierungen festgeschrieben oder zurückgesetzt werden.
- Fügen Sie den Nachrichtenfluss einem Brokerarchiv hinzu.
- Wählen Sie unterhalb der Editoransicht für die Brokerarchivierung die Registerkarte Konfigurieren aus und wählen Sie den Nachrichtenfluss aus. Daraufhin werden die konfigurierbaren Eigenschaften für den Nachrichtenfluss innerhalb des Brokerarchivs angezeigt. Wählen Sie koordinierte Transaktion aus, um den Nachrichtenfluss als global koordiniert zu konfigurieren.
Unter z/OS werden Transaktionen immer global
koordiniert. Die Einstellung der Eigenschaft koordinierte Transaktion für einen Nachrichtenfluss wird ignoriert. Die Koordination wird immer von RRS bereitgestellt.
Der Nachrichtenfluss ist damit für die globale Koordination
konfiguriert.
Sie können den Nachrichtenfluss jetzt auf dem Broker implementieren. Stellen Sie sicher, dass die Brokerumgebung (einschließlich Warteschlangenmanager des Brokers) und
die Datenbanken richtig für die globale Koordination konfiguriert werden, bevor Sie den
Nachrichtenfluss implementieren.
Andernfalls werden die Nachrichtenflusstransaktionen nicht
global koordiniert.