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
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
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.
XAResourceManager: Name=WBIWMQJMS SwitchFile=/<Installationspfad>/lib/JMSSwitch.so XAOpenString=<Ausgangskontextfactory>, <Position der JNDI-Bindungen>' <LDAP-Principal>, <LDAP-Berechtigungsnachweise>, <Name der Wiederherstellungs-Verbindungsfactory> ThreadOfControl=THREADDabei ist
<Installationspfad> die Position der WebSphere Message Broker-Installation. Dieser Wert ist obligatorisch.
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, , , myRecoveryQCFNameWenn für die LDAP-Parameter keine Angabe erfolgt, zur Wiederherstellung jedoch eine benutzerdefinierte Warteschlangenverbindungsfactory angegeben wird.
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.
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.
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.