Setzen Sie die Eigenschaft Transaktion
für die folgenden Knoten fest, wenn diese im Nachrichtenfluss angezeigt werden: - Rechenknoten
- Datenbankknoten
- Datenlöschknoten
- Dateneinfügeknoten
- Datenaktualisierungsknoten
- Filterknoten
- Zuordnungsknoten
- Warehouseknoten
Sie können die Eigenschaft Transaktion
auf folgende Werte setzen:
- Automatisch
- Alle Aktualisierungen, Löschungen und Zusätze, die der Knoten ausgeführt
hat, werden festgeschrieben oder zurückgesetzt, wenn die Verarbeitung im
Nachrichtenfluss beendet wurde. Wird der Nachrichtenfluss erfolgreich
ausgeführt, werden alle Änderungen festgeschrieben. Wird der Nachrichtenfluss
nicht erfolgreich ausgeführt, werden alle Änderungen zurückgesetzt.
Wenn
Sie alle Verarbeitungen des Nachrichtenflusses koordinieren möchten, müssen
Sie diesen Wert setzen.
- Festschreiben
- Die ausgeführte Aktion hängt von dem System ab, auf das der Nachrichtenfluss
implementiert wurde:
Wenn Sie Knoten mit Transaktionalität
Automatisch und
Festschreiben im gleichen
Nachrichtenfluss kombinieren möchten, müssen Sie getrennte
ODBC-Anschlüsse verwenden, wenn die Knoten auf derselben externen Datenbank
ausgeführt werden: einen Anschluss für die Knoten, die nicht vor Abschluss
des Nachrichtenflusses festgeschrieben werden und einen Anschluss für die
Knoten, die sofort festgeschrieben werden. Andernfalls werden die Knoten,
die sofort festgeschrieben werden, alle Operationen festschreiben, die von
vorangegangenen Knoten mit der Option
Automatisch ausgeführt wurden.
Anmerkung: Auf anderen Plattformen als z/OS wird diese Betriebsart nicht in allen Fällen von relationalen Datenbanken unterstützt.
Wenn Sie mehrere ODBC-Anschlüssen definieren,
können Probleme mit Datenbanksperren auftreten.
Insbesondere wenn ein Knoten mit der Transaktionalität Automatisch Operationen wie EINSETZEN oder AKTUALISIEREN ausführt, die zur Sperrung
eines Datenbankobjekts (z. B. einer Tabelle) führen, und der nachfolgende
Knoten versucht, mit einem anderen ODBC-Anschluss auf dieses Datenbankobjekt
zuzugreifen, kann eine endgültige Sperre (Deadlock) eintreten.
Der zweite Knoten wartet darauf, dass die vom ersten Knoten verursachte Sperre
entriegelt wird, aber der erste Knoten wird seine Operationen nicht festschreiben
und die Sperre entriegeln bevor der Nachrichtenfluss abgeschlossen ist. Dies wird
jedoch nicht eintreten, da der zweite Knoten darauf wartet, dass die Datenbanksperre
des ersten freigegeben wird.
Diese Situation kann nicht von einer
automatischen DBMS Deadlock-Vermeidungsroutine entdeckt werden, da die
beiden Operationen sich indirekt, über den Broker, gegenseitig behindern.
Sie haben zwei Möglichkeiten, diese Sperrprobleme zu vermeiden:
- Gestalten Sie Ihren Nachrichtenfluss so, dass nicht festgeschriebene
(automatische) Operationen keine Datenbankobjekte sperren, auf die nachfolgende
Operationen mit einem anderen ODBC-Anschluss zugreifen müssen.
- Konfigurieren Sie den Parameter des Zeitlimits für Sperren in der
Datenbank so, dass ein Versuch, eine Sperre einzurichten, nach einer vorgegebenen
Zeit fehlschlägt. Schlägt eine Datenbankoperation aufgrund des Zeitlimits für
Sperren fehl, wird eine Ausnahmebedingung ausgelöst, die der Broker ganz
normal bearbeitet.
Informationen, welche Datenbankobjekte durch bestimmte Operationen
gesperrt werden können und wie Sie den Parameter des Zeitlimits für Sperren
in Ihrer Datenbank konfigurieren, finden Sie in der Produktdokumentation
Ihrer Datenbank.
Setzen Sie die Eigenschaft Transaktionsmodus
für die folgenden Knoten fest, wenn sie im Nachrichtenfluss angezeigt werden: - MQEmpfangsknoten
- MQSenden
- MQAntwort
- SCADAEmpfangsknoten
- JMSEmpfangsknoten
- JMSSendeknoten
Die nachfolgende Tabelle zeigt eine Zusammenfassung der Aktionen,
die auf Grund bestimmter Einstellungen in den Eigenschaften für Eingabe- und Sendeknoten
ausgeführt wurden.
Nachrichtenpermanenz a |
Transaktionsmodus des Empfangsknoten |
Transaktionsmodus des MQSendeknotens oder des MQAntwortknotens |
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 |
Hinweise: - 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 MQSende- oder MQAntwortknotens überschrieben.
- Die Transaktionsmoduseinstellungen der JMSEmpfangs- und JMSSendeknoten werden anders als in der oben genannten Tabelle festgelegt. Weitere Informationen hierzu finden Sie unter JMSEmpfangsknoten und JMSSendeknoten.
Der Standardwert für jeden Empfangsknoten lautet Ja, was bedeutet, dass die eingehenden Nachrichten unter Synchronisationspunktsteuerung verarbeitet werden. Darüber hinaus werden Nachrichten, die an den Sendeknoten gesendet werden, unter Synchronisationspunktsteuerung zugestellt. Sie können dieses Verhalten ändern, wenn es sich beim Sendeknoten um einen MQSende- oder MQAntwortknoten handelt, die beide über die Eigenschaft Transaktionsmodus verfügen.
Wenn Sie den Transaktionsmodus in einem Empfangsknoten auf Automatisch setzen, werden die eingehenden Nachrichten nur unter der Synchronisationspunktsteuerung verarbeitet , wenn sie als permanent definiert sind. An den MQSendeknoten gesendete Nachrichten werden unter Synchronisationspunktsteuerung zugestellt, es sei denn, Sie ändern im MQSendeknoten explizit den Transaktionsmodus.