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.

Nachrichtenflusstransaktionen

Eine Transaktion beschreibt eine Gruppe von Aktualisierungen, die von einem Anwendungsprogramm durchgeführt werden und gemeinsam verwaltet werden müssen. Die Aktualisierungen können ein einziges oder mehrere Systeme betreffen. Die von dem Anwendungsprogramm durchgeführten Aktualisierungen werden von der Umgebung gesteuert, in der das Programm ausgeführt wird. Dabei werden entweder alle Aktualisierungen durchgeführt oder keine. Diese Eigenschaft einer Transaktion wird Konsistenz genannt. Transaktionen können weitere Eigenschaften besitzen wie Atomizität, Isolation und Dauerhaftigkeit.

WebSphere Message Broker unterstützt Transaktionen, wobei jedem Datenobjekt, das von einem Nachrichtenfluss verarbeitet wird, eine Transaktion zugeordnet ist. Eine Nachrichtenflusstransaktion wird vom Broker gestartet, wenn Eingabedaten bei einem Empfangsknoten im Nachrichtenfluss eintreffen. Sie wird festgeschrieben, nachdem der Nachrichtenfluss die Verarbeitung der Nachricht beendet hat, beziehungsweise zurückgesetzt, wenn ein Fehler auftritt.

Wenn der Nachrichtenfluss mehrere Empfangsknoten enthält, wird für jeden Empfangsknoten eine Transaktion gestartet, sobald dort Eingabedaten empfangen werden. Eine Transaktion wird für jeden Empfangsknotentyp gestartet, auch für benutzerdefinierte Empfangsknoten.

Die Knoten, die Sie in einen Nachrichtenfluss einschließen können, führen gemäß der definierten Funktion jedes einzelnen Knotens eine bestimmte Verarbeitung durch. Im Rahmen dieser Verarbeitung finden interne Arbeitsschritte statt, die Sie beeinflussen können, indem Sie Knoteneigenschaften konfigurieren. Einige Knoten führen zusätzliche Tasks aus, die externe Systeme betreffen können, also Systeme, die außerhalb des Nachrichtenflusses oder Brokers liegen.

Wenn ein externes System, z. B. eine Datenbank, das Konzept von Festschreibung und Rücksetzung (Rollback) unterstützt und in der Lage ist, an einer Brokertransaktion mitzuwirken, können Sie den Knoten so konfigurieren, dass die dort ausgeführten Arbeitsschritte in die Nachrichtenflusstransaktion integriert werden. Abhängig vom Knoten können Sie auch angeben, ob die Arbeitsschritte, die in einem externen System, das Transaktionen unterstützt, ausgeführt werden, sofort oder erst nach Abschluss der Nachrichtenflusstransaktion festgeschrieben werden.

Viele der Ressourcen, mit denen Nachrichtenflüsse interagieren können, werden von Ressourcenmanagern gesteuert, die an koordinierten Transaktionen mitwirken können; dies gilt beispielsweise für Datenbanken, WebSphere MQ-Nachrichten und -Warteschlangen sowie JMS-Nachrichten. Andere Ressourcenmanager, z. B. das HTTP-Protokoll und Dateisysteme, bieten keine Transaktionsunterstützung.

Festschreiben oder zurücksetzen

Wenn die Ressource an einer Transaktion mitwirken kann, können Sie sie so konfigurieren, das die von ihr ausgeführten Arbeitsschritte nur dann festgeschrieben oder zurückgesetzt werden, wenn entweder die Nachrichtenfluss- oder die Knotenverarbeitung abgeschlossen ist. Datenbanken und WebSphere MQ-Warteschlangen sind Beispiele für Ressourcen, die auf diese Weise verwendet werden können. Wenn die Ressource kein Transaktionsverhalten aufweist, werden alle von ihr ausgeführten Arbeitsschritte sofort festgeschrieben. Beispielsweise unterstützen Dateien und HTTP-Verbindungen keine Transaktionen.

Von einem Nachrichtenfluss durchgeführte Aktualisierungen werden festgeschrieben, sobald der Nachrichtenfluss die Verarbeitung der Eingabenachricht erfolgreich abgeschlossen hat. Die Aktualisierungen werden zurückgesetzt, wenn die beiden folgenden Bedingungen erfüllt sind:

Auf verteilten Systemen werden Nachrichtenflusstransaktionen standardmäßig vom Broker verwaltet. Diese Transaktionen werden als brokerkoordinierte Transaktionen oder teilweise koordinierte Transaktionen bezeichnet. Wenn die Steuerung nach Abschluss der Verarbeitung an den Empfangsknoten zurückgegeben wird, schreibt der Knoten die ausgeführten Operationen entweder fest oder er setzt sie zurück. Dies gilt nicht für die Einzelknoten, für die eigene Festschreibungs- und Rücksetzungsabläufe konfiguriert wurden oder die diese Option nicht unterstützen.

Wenn der Nachrichtenfluss auf mehrere Ressourcen zugreift, kann ein Fehler auftreten, der alle Ressourcen daran hindert, alle ausgeführten Arbeitsschritte festzuschreiben. Der Broker löst eine Ausnahme aus und führt die Ausnahmebehandlung auf eine Weise durch, die von der einbezogenen Transportmethode bestimmt wird. Beispielsweise werden Nachrichten, die aus WebSphere MQ-Warteschlangen gelesen wurden, in diesen Warteschlangen wiederhergestellt und an Anwendungen, die über HTTP eine Nachricht übergeben haben, werden Fehlernachrichten gesendet (weil HTTP kein Rollback-Konzept besitzt). Aufgrund dieser Aktionen kann der Status der Ressourcen inkonsistent werden.

Wenn es wichtig ist, dass Ihre Daten und Operationen konsistent bleiben und dass alle Operationen festgeschrieben werden bzw. zurückgesetzt werden, falls eine oder mehrere Operationen fehlschlagen, können Sie die Aktivität des Nachrichtenflusses koordinieren. Die Koordination wird von einem externen Transaktionsmanager bereitgestellt, der über XA-Protokolle mit Ressourcenmanagern interagiert. Der Transaktionsmanager wird vom Empfangsknoten aufgerufen, sobald der Nachrichtenfluss die Verarbeitung beendet hat (erfolgreich oder mit Fehlern). Statt des Empfangsknotens und des Brokers interagiert der Transaktionsmanager mit den relevanten Ressourcenmanagern, um die richtigen Aktionen für jede Ressource einzuleiten. Transaktionen, die auf diese Weise von einem Transaktionsmanager gesteuert werden, werden als global koordinierte Transaktionen bezeichnet.

Unter z/OS werden Transaktionen immer global koordiniert, sodass Sie diese Option nicht auswählen oder konfigurieren müssen.

Eine ausführliche Beschreibung des Transaktionsmodells im Broker finden Sie im Abschnitt Transaktionsorientiertes Modell.

Rolle des Transaktionsmanagers

Das Ergebnis der von Nachrichtenflüssen ausgeführten Aktionen ist für teilweise und für global koordinierte Transaktionen dasselbe, wenn alle Aktionen des Nachrichtenflusses erfolgreich abgeschlossen werden. Eine global koordinierte Transaktion hat den Vorteil, dass durch sie sichergestellt werden kann, dass entweder alle Aktionen festgeschrieben werden oder keine.

Der externe Transaktionsmanager, der eine zweiphasige Festschreibungsstrategie verfolgt, unterstützt Fälle, in denen ein oder mehrere externe Ressourcenmanager während der Commitverarbeitung vorübergehend nicht verfügbar sind. Dieses potenziell kleine Fehlerfenster kann für eine Geschäftsumgebung kostspielig sein; der externe Transaktionsmanager hilft dabei, das Auftreten eines Fehlerfensters zu verhindern. Deshalb ist die Entscheidung, ob ein externer Transaktionsmanager, der zu Leistungseinbußen führt, eingebunden wird, eine Verwaltungsentscheidung und keine, die bei der Nachrichtenflussentwicklung getroffen werden muss.

Ein externer Transaktionsmanager verhindert keinen Nachrichtenverlust. Auch bei Verwendung einer Transaktionskoordination müssen Sie die Nachrichtenflüsse so gut wie möglich für die Behandlung potenzieller Fehler konfigurieren und codieren.

Um einen Nachrichtenfluss für die globale Koordination zu konfigurieren, müssen Sie auch Ihre Umgebung entsprechend einrichten, damit die Ressourcenmanager für den unterstützten Transaktionsmanager definiert sind:

Für diese Konfiguration müssen Sie gegebenenfalls Einstellungen im Transaktionsmanager sowie im beteiligten Ressourcenmanager ändern.

Datenbankzugriffsmodi und -sperren

Sie müssen separate ODBC-Verbindungen verwenden, wenn Sie Knoten mit dem Transaktionsstatus Automatisch und Festschreiben im selben Nachrichtenfluss einsetzen möchten und diese mit derselben externen Datenbank arbeiten sollen. Richten Sie eine Verbindung für die Knoten ein, die erst bei Abschluss des Nachrichtenflusses festgeschrieben werden sollen, sowie eine zweite Verbindung für die Knoten, die sofort festgeschrieben werden sollen.

Linux platformUNIX platformWindows platformUnter anderen Systemen als z/OS wird diese Betriebsart nicht in allen Fällen von relationalen Datenbanken unterstützt.

Wenn Sie mehrere ODBC-Verbindungen für dieselbe Datenquelle definieren, treten möglicherweise Probleme in Bezug auf Datenbanksperren auf. Insbesondere bedeutet dies Folgendes: Wenn ein Knoten mit dem Transaktionsstatus Automatisch eine Operation wie beispielsweise INSERT oder UPDATE ausführt, die zur 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 (Deadlock) 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 erst frei, wenn der Nachrichtenfluss abgeschlossen ist. Dies kann jedoch nicht eintreten, da der zweite Knoten darauf wartet, dass die vom ersten Knoten eingerichtete Datenbanksperre freigegeben wird.

Eine derartige Situation kann von einer DBMS-Routine zur automatischen Vermeidung von gegenseitigen Sperren nicht erkannt werden, da sich die beiden Operationen durch Verwendung des Brokers indirekt behindern.

Diese Art der Sperre kann auf zwei Arten vermieden werden:

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 kann.

Transaktionsbeispiele in Nachrichtenflüssen

Das folgende Beispiel veranschaulicht die Verwendung von global koordinierten Transaktionen und zeigt die unterschiedlichen Abläufe im Nachrichtenfluss, wenn Datenbankaktualisierungen koordiniert werden (Hauptnachrichtenfluss) und wenn nicht (Fehlernachrichtenfluss).

Informationen zu Beispielen können nur bei Verwendung des in das WebSphere Message Broker Toolkit integrierten bzw. online verfügbaren Information Center angezeigt werden. Muster können nur ausgeführt werden, wenn das im WebSphere Message Broker Toolkit integrierte Information Center verwendet wird.

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

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

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


KonzeptthemaKonzeptthema | Version 8.0.0.5 | ac00645_