This topic contains sections marked as revised for this release

WebSphere Message Brokers
File: ac24879_
Writer: John Cooper

Concept topic

This build: July 31, 2007 21:19:45

JMS Transactionality

JMS destinations that supply messages to a JMSInput node, or receive messages from a JMSOutput node, can be syncpoint coordinated as part of a message flow global transaction.

Transactions involving the Syncpoint coordinator

A diagram that depicts the message flow through a JMSInput node and a JMSOutput node, including a Synchpoint coordinator.

In this diagram, messages are consumed from a topic 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 Syncpoint 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 Syncpoint 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 a global transaction.

The external Syncpoint Coordinator is WebSphere MQ on platforms other than z/OS, and RRS (Resource Recovery Services) on z/OS.

The JMSInput node and JMSOutput node can participate in a global 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 Syncpoint 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 platforms other than z/OS, WebSphere MQ requires an administration task to be carried out prior to 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 Syncpoint 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 global transaction support for the JMSInput and JMSOutput nodes; see Configuring JMSInput and JMSOutput nodes to support global transactions.

Related tasks
Configuring JMSInput and JMSOutput nodes to support global transactions
Related reference
JMS message types
JMS message structure
JNDI administered objects
JMSInput node
JMSOutput node
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:19:45

ac24879_ This topic's URL is: