JMS-Transaktionalität

JMS-Zieladressen, die Nachrichten an einen JMSEmpfangsknoten senden oder Nachrichten von einem JMSSendeknoten empfangen, können als Teil einer globalen Nachrichtenfluss-Transaktion der Synchronisationspunktsteuerung unterliegen.

Transaktionen unter Verwendung des Synchronisationspunkt-Koordinators

Abbildung des Nachrichtenflusses durch einen JMSEmpfangsknoten und einen JMSSendeknoten, einschließlich eines Synchronisationspunkt-Koordinators

In dieser Abbildung werden Nachrichten aus einem Thema von einem JMSEmpfangsknoten empfangen und an die JMS-Warteschlange eines JMSSendeknotens ausgegeben. Die Knoten werden mit einem JMS-Provider verbunden und unterhalten eine Sitzung mit diesem. Jeder Empfangsknoten im Nachrichtenfluss kann den externen Koordinator der Synchronisationspunktsteuerung darüber informieren, wann ein Nachrichtenfluss beginnt und endet, und ob Ressourcen, die von dem Fluss betroffen sind, festgeschrieben oder zurückgesetzt werden sollen.

Der Synchronisationspunkt-Koordinator sendet XA/Open-kompatible Anforderungen an alle teilnehmenden Ressourcenmanager zu deren Vorbereitung. Änderungen werden dann entweder festgeschrieben oder zurückgestellt. Ressourcenmanager wie beispielsweise WebSphere MQ, DB2 und alle XA-kompatiblen JMS-Provider können an einer globalen Transaktion mitwirken. Als externer Synchronisationspunkt-Koordinator auf verteilten Plattformen agiert WebSphere MQ, unter z/OS ist es RRS (Resource Recovery Services).

Der JMSEmpfangsknoten und der JMSSendeknoten können nur an einer globalen Transaktion mitwirken, wenn der JMS-Provider, mit dem sie sich verbinden, die XA/Open-Schnittstelle über die JMS-Klasse XAResource unterstützt. Der WebSphere MQ-Java Client ist beispielsweise ein solcher JMS-Provider.

Unbestätigte Transaktionen

Unbestätigte Transaktionen können auftreten, wenn ein Ressourcenmanager nicht auf einen Aufruf des Synchronisationspunktmanagers zur Festschreibung oder Rücksetzung von Ressourcen antwortet. Während des Starts des WebSphere MQ-Warteschlangenmanagers des Brokers wird eine erste Fehlerbehebungsmaßnahme durchgeführt, um sicherzustellen, dass alle unbestätigten Transaktionen aufgelöst werden, bevor die Nachrichtenflüsse des Brokers mit der Verarbeitung neuer Eingaben beginnen. Ein JMS-Provider, der an globalen Brokertransaktionen mitwirkt, wird in diese Fehlerbehebungsmaßnahme aufgenommen.

Konfiguration zum Aktivieren der globalen Transaktionsunterstützung

Damit die globale Transaktionsunterstützung für den JMSEmpfangs- und JMSSendeknoten ermöglicht wird, sind zusätzliche Konfigurationsschritte erforderlich. Führen Sie folgende Schritte aus:
  1. Setzen Sie die Nachrichtenflusseigenschaft Koordinierte Transaktion auf yes.
  2. Für jeden JMSEmpfangs- oder JMSSendeknoten, der an der globalen Transaktion mitwirken soll, muss die erweiterte Eigenschaft Transaktionsmodus auf global gesetzt werden.
  3. Erstellen Sie eine Warteschlangenverbindungsfactory, und geben Sie entweder einen Standardnamen, recoverXAQCF oder einen benutzerdefinierten Namen an. Die Abschnitte zum JMSEmpfangsknoten oder JMSSendeknoten enthalten detaillierte Informationen zur Erstellung der von JNDI verwalteten Objekte.
  4. Auf verteilten Plattformen ist vor der Implementierung eine Verwaltungstask von WebSphere MQ erforderlich. Diese Task muss zur Registrierung einer Brokerkomponente beim Warteschlangenmanager ausgeführt werden. Bei der Komponente, die als Switch-Datei bezeichnet wird, handelt es sich um eine gemeinsam genutzte Bibliothek (eine DLL-Datei unter Windows).

    Wenn der WebSphere MQ-Warteschlangenmanager des Brokers startet, wird die Switch-Datei geladen. Die Switch-Datei leitet XA/Open-Transaktionsaufrufe vom Koordinator der Synchronisationspunktsteuerung an den JMS-Provider weiter. Auf diese Weise wird sichergestellt, dass die JMS-Ressourcen, die an der Transaktion mitwirken, bezüglich der Synchronisation mit anderen Ressourcenmanagern in derselben Transaktion koordiniert werden können.

    Die Task unterscheidet sich je nach Plattform.
    • Linux und UNIX
      Platzieren Sie für den Broker-Warteschlangenmanager für jeden JMS-Provider, der von einem JMSEmpfangsknoten verwendet werden kann, einen Zeilengruppeneintrag in eine Initialisierungsdatei, beispielsweise in die Datei 'qm.ini'. Das nachfolgende Beispiel zeigt einen Zeilengruppeneintrag, den Sie hinzufügen können, wenn Sie WebSphere MQ Java als JMS-Provider verwenden:
      XAResourceManager:  
      	Name=WBIWMQJMS 
          SwitchFile=/<Installationspfad>/lib/JMSSwitch.so
          XAOpenString=<Ausgangskontextfactory>,
                    <Position der JNDI-Bindungen>'
                    <LDAP-Principal>,
                    <LDAP-Berechtigungsnachweise>,
                    <Name der Wiederherstellungs-Verbindungsfactory>
          ThreadOfControl=THREAD
      Dabei ist

      <Installationspfad> die Position der WebSphere Message Broker-Installation. Dieser Wert ist obligatorisch.

      Die in XAOpenString übergebenen Parameter sind durch Kommas getrennt und positionsgebunden. Fehlende optionale Parameter müssen durch ein Komma dargestellt werden, wenn weiter hinten in der Zeichenfolge sonstige Parameter angegeben werden.
      • <Ausgangskontext-Factory> Dies ist die ID für die Ausgangskontext-Factory für den JMS-Provider. Dieser Wert ist obligatorisch.
      • <Position der JNDI-Bindungen> Dies ist entweder der Dateipfad zur Bindungsdatei oder der Pfad des LDAP-Verzeichnisses der von JNDI verwalteten Objekte, die zur Erstellung einer Ausgangskontext-Factory für die JMS-Verbindung verwendet werden können. Geben Sie nicht den Dateinamen mit an, wenn Sie den Dateipfad der Bindungsdatei angeben. Die Abschnitte zum JMSEmpfangs- oder JMSSendeknoten enthalten detaillierte Informationen zur Erstellung der von JNDI verwalteten Objekte. Dieser Wert ist obligatorisch.
      • <LDAP-Principal> Dies ist ein optionaler Parameter zur Angabe des Principals (Benutzer-ID), der erforderlich sein kann, wenn eine LDAP-Datenbank zum Speichern der von JNDI verwalteten Objekte verwendet wird.
      • <LDAP-Berechtigungsnachweise> ist ein optionaler Parameter zur Angabe der Berechtigungsnachweise (Kennwort), die erforderlich sein können, wenn eine kennwortgeschützte LDAP-Datenbank zum Speichern der von JNDI verwalteten Objekte verwendet wird.
      • <Name der Wiederherstellungs-Verbindungsfactory> Dies ist ein optionaler Parameter zur Angabe des Namens eines Warteschlangenverbindungsfactory-Objekts in den von JNDI verwalteten Objekten zur Wiederherstellung, wenn der vom Standard abweichende Name erforderlich ist.

      Sie müssen in der '.ini'-Datei des Broker-Warteschlangenmanagers eine Zeilengruppe für jeden neuen JMS-Provider angeben, den Sie verwenden möchten, d. h., für jeden neuen JMS-Provider sollte eine Zeilengruppe vorhanden sein, wobei der JMS-Provider von jedem JMSEmpfangs- oder JMSSendeknoten in einem Nachrichtenfluss angegeben werden kann, der auf diesem Broker ausgeführt wird.

      Die Werte für 'Ausgangskontextfactory' und 'Position der JNDI-Bindungen' in der Zeilengruppe müssen den Werten entsprechen, die in den JMSEmpfangs- oder JMSSendeknoten in den Nachrichtenflüssen angegeben sind.

      Alle LDAP-Parameter müssen denen entsprechen, die für diesen Broker mit dem Befehl mqsicreatebroker oder mqsichangebroker angegeben werden.

      Der Name der Wiederherstellungsfactory muss dem Namen einer Warteschlangenverbindungsfactory entsprechen, die in den von JNDI verwalteten Objekten erstellt wurde. Wird kein Wert angegeben, wird eine Standardwertfactory mit der Bezeichnung recoverXAQCF verwendet. In beiden Fällen muss dieser Wert auf ein JNDI-verwaltetes Objekt verweisen, das bereits erstellt wurde.

      Nachfolgend sehen Sie ein Zeilengruppenbeispiel:

      XAOpenString=com.sun.jndi.fscontext.RefFSContextFactory,
           /u/myJndiFileLocation,
           ,
           ,
           myRecoveryQCFName    
      Wenn für die LDAP-Parameter keine Angabe erfolgt, zur Wiederherstellung jedoch eine benutzerdefinierte Warteschlangenverbindungsfactory angegeben wird.
    • Auf Windows-Plattformen

      Unter Windows sind dieselben Informationen erforderlich wie bei Linux und Unix, sie werden jedoch mit dem WebSphere MQ-Explorer oder dem Snap-in WebSphere MQ Services konfiguriert, je nachdem, welche Version von WebSphere MQ verwendet wird. Unter Windows heißt die Switch-Datei JMSSwitch.dll. Weitere Informationen zur Aktualisierung der Datei 'qm.ini' finden Sie im Handbuch WebSphere MQ System Administration Guide. Der zusätzliche Eintrag namens XACloseString sollte den Werten entsprechen, die für XAOpenString angegeben werden.

    • Unter z/OS

      In WebSphere Message Broker wird derzeit nur IBM WebSphere MQ Java Client als JMS-Provider unterstützt. Der einzige derzeit für den Client unterstützte Transportmodus ist der Modus BIND. Es sind keine weiteren Konfigurationsschritte erforderlich.

    Weitere Informationen finden Sie im Abschnitt über die Konfiguration von koordinierten Transaktionen in den Kapiteln über den JMSEmpfangsknoten und den JMSSendeknoten.
  5. Der JMS-Provider kann zusätzliche JAR-Dateien bereitstellen, die zur Transaktionsunterstützung erforderlich sind. Weitere Informationen erhalten Sie in der Dokumentation des JMS-Providers. Auf verteilten Plattformen (keine z/OS-Plattformen) stellt der JMS Provider von WebSphere MQ beispielsweise die zusätzliche JAR-Datei 'com.ibm,mqetclient.jar' zur Verfügung. Diese JAR-Datei muss auch zum Verzeichnis 'shared_classes' des Brokers hinzugefügt werden. Unter Windows lautet dieses Verzeichnis C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\IBM\MQSI\shared-classes. Weitere Informationen finden Sie im Abschnitt zum Bereitstellen des JMS-Provider-Clients für JMS-Knoten in den folgenden Themen: JMSEmpfangsknoten.

Wahl des JMS-Providers

Wenn eine Transaktionskoordination erforderlich ist, kann jeder JMS-Provider verwendet werden, der der Java Message Service Specification, Version 1.1 entspricht und über die JMS-Sitzung die JMS-API 'XAResource' unterstützt.

Wenn der Nachrichtenentwickler einen nicht XA-kompatiblen Provider angegeben hat, wird nur der Nicht-Transaktionsmodus unterstützt, und der Nachrichtenentwickler muss auch die Eigenschaft Transaktionsmodus für alle JMSEmpfangs- und JMSSendeknoten auf no setzen.

Zugehörige Verweise
JMS-Nachrichtentypen
JMS-Nachrichtenstruktur
Von JNDI verwaltete Objekte
JMSEmpfangsknoten
JMSSendeknoten
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ac24879_