JMS transactionality
JMS destinations that supply messages to an input node, or receive messages from an output node, can be sync-point coordinated as part of a message flow XA coordinated transaction.
Transactions involving the sync-point coordinator
In this diagram, messages are consumed from a queue by a JMSInput node, and are produced to a JMS queue by a JMSOutput node. The nodes are connected to, and are in session with, a JMS provider. Any message flow input node can inform the external sync-point coordinator when a message flow transaction starts and ends, and whether any resources that have been affected by the flow should be committed or rolled back.
The sync-point coordinator sends XA/Open compliant requests to all participating resource managers to inform them to prepare. Any changes are either committed or rolled back. Resource managers, for example, WebSphere® MQ, IBM® DB2® and any XA compliant JMS provider can participate in an XA coordinated transaction.
On distributed systems, WebSphere MQ is the external sync-point coordinator (transaction manager), which means that IBM Integration Bus must have access to WebSphere MQ when it is processing the messages in the flow. On z/OS®, Resource Recovery Services (RRS) is the external sync-point coordinator. For more information about using WebSphere MQ with IBM Integration Bus, see Installing WebSphere MQ.
On z/OS, the only JMS provider that is supported is the IBM WebSphere MQ Java™ Client, and the only transport mode supported for that client is BIND mode.
Nodes that use JMS transport, such as the JMS and SOAP nodes, can
participate in an XA coordinated transaction only if the
JMS provider to which they connect supports the XA/Open interface
through the JMS XAResource Class. An example JMS
provider is the WebSphere MQ Java Client.
You can specify a generic connection factory (recoverXAQCF)
for recovery of XA coordinated transactions.
In-doubt transactions
In-doubt transactions can occur when a resource manager does not reply to a call from the sync-point manager, where the call is to commit or to rollback resources. During start up of the integration node's WebSphere MQ queue manager, an initial recovery step is taken to ensure that any in-doubt transactions are resolved before the integration node message flows start to process new input. A JMS provider that participates in integration node global transactions is included in this recovery step.
On operating systems other than z/OS, WebSphere MQ requires an administration task to be carried out before deployment. This task registers an integration node component, which is a shared library, with the queue manager by referring the shared library to a switch file.
When the integration node's WebSphere MQ queue manager starts up, it loads the switch file. The switch file forwards XA/Open transaction calls from the sync-point coordinator to the JMS Provider. This ensures that the JMS resources that participate in the transaction can be coordinated in synchronization with other resource managers that are involved in the same transaction.
Additional configuration is required to enable XA coordinated transaction support for the nodes using JMS transport; see Configuring JMS and SOAP nodes to support globally coordinated transactions.