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
In this diagram, messages are consumed from a topic by a JMSInput node, and are produced to a JMS queue JMSOutput node. The nodes are connected with 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 touched 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 then either committed or rolled back. Resource Managers such as WebSphere MQ, DB2 and any XA compliant JMS provider can participate in a global transaction. The external Syncpoint Coordinator is WebSphere MQ on distributed platforms, 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.
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.
Configuration to enable global transaction support
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.
XAResourceManager: Name=WBIWMQJMS SwitchFile=/<Installation Path>/lib/JMSSwitch.so XAOpenString=<Initial Context Factory>, <location of JNDI bindings>' <LDAP Principal>, <LDAP Credentials>, <Recovery Connection Factory Name> ThreadOfControl=THREADWhere:
<Installation Path> is the location of the WebSphere Message Broker installation. This value is mandatory.
You must specify a stanza in the broker's queue manager .ini file for each JMS provider that you want to use, that is, there should be one stanza for each new JMS provider, where the JMS provider can be specified by any JMSInput or JMSOutput node included in a message flow that is running on a broker.
The values for the Initial Context factory and Location of JNDI bindings in the stanza must match those specified in the JMSInput or JMSOutput nodes in the message flows.
Any LDAP parameters must match those which have been specified by using the mqsicreatebroker or mqsichangebroker command.
The Recovery Factory Name must match a Queue Connection Factory name that is created in the JNDI administered objects. If this is omitted, a default factory called recoverXAQCF is used. In either case this value must refer to a JNDI administered object that has already been created.
The following is an example stanza:
XAOpenString=com.sun.jndi.fscontext.RefFSContextFactory, /u/myJndiFileLocation, , , myRecoveryQCFNameWhere the LDAP parameters are omitted, but a user defined Queue Connection Factory is specified for recovery.
As with Linux and Unix, the same information is required on Windows but it is configured using the WebSphere MQ Explorer or WebSphere MQ Services snap-in depending on which version of WebSphere MQ you are using. On Windows, the Switch file is called JMSSwitch.dll. Refer to the WebSphere MQ System Administration Guide for details on how to update the qm.ini file. The extra entry, called the XACloseString, should match the values provided for the XAOpenString.
In WebSphere Message Broker the only JMS provider currently supported is the IBM WebSphere MQ Java Client. The only transport mode currently supported for the client is BIND mode. No further configuration steps are required
Any JMS provider that conforms to the Java Message Service Specification, version 1.1 and that supports the JMS XAResource API through the JMS session can be used if transaction coordination is required.
If the message designer has specified a non XA compliant provider, the non transactional mode only is supported. In this case, you must set the Transaction mode property to no for all JMSInput and JMSOutput nodes.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac24879_ |