XA-Switchstruktur von IBM MQ

Jeder an einer extern koordinierten Arbeitseinheit beteiligte Ressourcenmanager muss eine XA-Switchstruktur bereitstellen. Diese Struktur definiert sowohl die Funktionalität des Ressourcenmanagers als auch die Funktionen, die vom Synchronisationspunktkoordinator aufgerufen werden müssen.

IBM® MQ stellt zwei Versionen dieser Struktur bereit:

MQRMIXASwitch für die statische XA-Ressourcenverwaltung
MQRMIXASwitchDynamic für die dynamische XA-Ressourcenverwaltung

Schlagen Sie in der Dokumentation zu Ihrem Transaktionsmanager nach, ob die Schnittstelle für die statische oder die dynamische Ressourcenverwaltung verwendet werden soll. Sofern der Transaktionsmanager dies unterstützt, empfehlen wir die Verwendung der dynamischen XA-Ressourcenverwaltung.

Der Datentyp long in der XA-Spezifikation wird von manchen 64-Bit-Transaktionsmanagern als 64-Bit und von manchen als 32-Bit behandelt. IBM MQ unterstützt beide Modelle:

Wenn Ihr Transaktionsmanager 32-Bit ist oder Ihr Transaktionsmanager 64-Bit ist, aber den long Typ als 32-Bit behandelt, verwenden Sie die in Tabelle 1 aufgeführte Switch-Load-Datei.
Wenn Ihr Transaktionsmanager 64-Bit ist und den long als 64-Bit behandelt, verwenden Sie die in Tabelle 2 aufgeführte Switch-Load-Datei.

Einige 64-Bit-Transaktionsmanager behandeln den Datentyp long als 64-Bit-Version. Für folgende 64-Bit-Transaktionsmanager ist bekanntermaßen die alternative 64-Bit-Switchloaddatei erforderlich:

Tuxedo
64 Bit TXSerie

Wenn Sie nicht sicher sind, welches Modell Ihr Transaktionsmanager verwendet, konsultieren Sie die Dokumentation zu Ihrem Transaktionsmanager.

Tabelle 1. Namen von XA-Switchloaddateien
Plattform	Name der Switchloaddatei (Server)	Name der Switchloaddatei (erweiterter transaktionsorientierter Client)
Windows	mqmxa.dll	mqcxa.dll
AIX® (ohne Gewinde)	libmqmxa.a	libmqcxa.a
AIX (mit Gewinde)	libmqmxa_r.a	libmqcxa_r.a
Linux® (ohne Gewinde)	libmqmxa.so	libmqcxa.so
Linux (mit Gewinde)	libmqmxa_r.so	libmqcxa_r.so

Tabelle 2. Namen alternativer 64-Bit-XA-Switchloaddateien
Plattform	Name der Switchloaddatei (Server)	Name der Switchloaddatei (erweiterter transaktionsorientierter Client)
AIX (ohne Gewinde)	libmqmxa64.a	libmqcxa64.a
AIX (mit Gewinde)	libmqmxa64_r.a	libmqcxa64_r.a
Linux (ohne Gewinde)	libmqmxa64.so	libmqcxa64.so
Linux (mit Gewinde)	libmqmxa64_r.so	libmqcxa64_r.so

Einige externe Synchronisationspunktkoordinatoren (nicht CICS® ) Erfordert, dass jeder Ressourcenmanager, der an einer Arbeitseinheit teilnimmt, seinen Namen im Namensfeld der XA-Switchstruktur angibt. Der Name des IBM MQ -Ressourcenmanagers lautet MQSeries_XA_RMI.

Der Synchronisationspunktkoordinator definiert, wie die IBM MQ XA-Switchstruktur eine Verbindung zu ihm herstellt. Informationen über die Verknüpfung der IBM MQ XA-Schalterstruktur mit CICS finden Sie in Using CICS. Informationen zur Verknüpfung der XA-Switchstruktur von IBM MQ mit anderen XA-kompatiblen Synchronisationspunktkoordinatoren finden Sie in der Dokumentation zu diesen Produkten.

Die folgenden Hinweise gelten für die Verwendung von IBM MQ mit allen XA-kompatiblen Synchronisationspunktkoordinatoren:

Es wird erwartet, dass der Bibliothekscode des Transaktionsmanagers (der als Teil ihrer API ausgeführt wird, die der Anwendungsprogrammierer aufgerufen hat) xa_open in IBM MQ aufruft, bevor MQCONN aufgerufen wird.
Der xa_open-Aufruf muss im gleichen Thread erfolgen wie der MQCONN-Aufruf. Erforderlich macht dies die XA-Spezifikation, in der festgelegt ist, dass der Thread den Kontext angibt.

Diesen Ansatz verfolgt auch das Beispielprogramm amqstxsx.c. Dieses Beispielprogramm setzt voraus, dass ein xa_open -Aufruf in IBM MQaus dem Bibliothekscode des Transaktionsmanagers in ihrer Funktion tpopenerfolgt.

Wenn vor dem MQCONN-Aufruf kein xa_open -Aufruf für denselben Thread ausgeführt wird, wird die IBM MQ -Warteschlangenmanagerverbindung keinem XA-Kontext zugeordnet.

Weitere Informationen finden Sie im Abschnitt MQCTL.
Die xa_info-Struktur, die in jedem xa_open-Aufruf vom Synchronisationspunktkoordinator übergeben wird, enthält den Namen eines IBM MQ -Warteschlangenmanagers. Der Name hat dasselbe Format wie der an den Aufruf MQCONN übergebene Warteschlangenmanagername. Falls im Aufruf 'xa_open' kein Name übergeben wird, wird der Standardwarteschlangenmanager verwendet.
Alternativ dazu können in der Struktur 'xa_info' Werte für die Parameter TPM und AXLIB enthalten sein. Mit dem Parameter TPM wird der verwendete Transaktionsmanager angegeben. Gültig sind die Werte CICS, TUXEDO und ENCINA. Der Parameter AXLIB gibt den Namen der Bibliothek an, in der die Funktionen 'ax_reg' und 'ax_unreg' des Transaktionsmanagers enthalten sind. Weitere Informationen zu diesen Parametern finden Sie unter Erweiterten transaktionsorientierten Client konfigurieren. Falls einer dieser Parameter in der Struktur 'xa_info' enthalten ist, wird der Warteschlangenmanagername im Parameter QMNAME angegeben, sofern nicht der Standardwarteschlangenmanager verwendet wird.
An einer Transaktion, die von einer Instanz eines externen Synchronisationspunktkoordinators koordiniert wird, kann immer nur jeweils ein Warteschlangenmanager beteiligt sein. Der Synchronisationspunktkoordinator wird mit dem Warteschlangenmanager verbunden und für ihn gilt die Regel, dass nur jeweils eine Verbindung unterstützt wird.
Alle Anwendungen, die Aufrufe an einen externen Synchronisationspunktkoordinator umfassen, können nur zu dem Warteschlangenmanager eine Verbindung herstellen, der an der vom externen Koordinator verwalteten Transaktion beteiligt ist (da sie bereits mit diesem Warteschlangenmanager verbunden sind). Allerdings müssen diese Anwendungen einen Aufruf MQCONN zur Anforderung einer Verbindungskennung und einen Aufruf MQDISC ausgeben, bevor sie beendet werden.
Ein Warteschlangenmanager mit Ressourcenaktualisierungen, die von einem externen Synchronisationspunktkoordinator koordiniert werden, muss vor dem externen Synchronisationspunktkoordinator gestartet werden. Ebenso muss der Synchronisationspunktkoordinator vor dem Warteschlangenmanager beendet werden.
Wenn der externe Synchronisationspunktkoordinator abnormal beendet wird, stoppen und starten Sie den Warteschlangenmanager erneut, bevor Sie den Synchronisationspunktkoordinator erneut starten, um sicherzustellen, dass alle Messagingoperationen, die zum Zeitpunkt des Fehlers nicht festgeschrieben waren, ordnungsgemäß aufgelöst werden.