IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

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

A diagram that depicts the message flow through a JMSInput node and a JMSOutput node, including a 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, DB2® and any XA compliant JMS provider can participate in an XA coordinated transaction.

The external sync-point coordinator is WebSphere MQ on operating systems other than z/OS®, and RRS (Resource Recovery Services) on z/OS.

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 broker's WebSphere MQ queue manager, an initial recovery step is taken to ensure that any in-doubt transactions are resolved before the broker message flows start to process new input. A JMS provider that participates in broker 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 a broker component, which is a shared library, with the queue manager by referring the shared library to a switch file.

When the broker'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 XA coordinated transactions.


ac24879_.htm | Last updated Friday, 21 July 2017