Configuring WebSphere Application Server to connect via a Client Channel Definition Table to a WMQ queue manager for Global Transaction (XA) capability.
How to configure WebSphere Application Server (WAS) to connect via a Client Channel Definition Table (CCDT) to a WebSphere MQ (WMQ) queue manager for Global Transaction (XA) capability.
For the WebSphere MQ client, XA capability is available only if you use the Extended Transactional Client or within an application server environment such as WebSphere Application Server (WAS). If you require XA functionality in an application server environment, you must configure your application appropriately.
Note: XA is not supported during automatic client reconnect. Automatic client reconnect is not supported within application server processes as it can cause issues with XA transactions. For more information about automatic client reconnection, refer to this technote:
"Using WebSphere MQ automatic client reconnection with the WebSphere MQ classes for JMS"
If you are using a Client Channel Definition Table (CCDT) to connect from WebSphere Application Server to a WebSphere MQ queue manager, the following table shows the configurations in which XA is and is not supported:
- Using a CCDT to connect to multiple different queue managers
- Using a CCDT to connect to multiple multi-instance queue managers
- CCDT connecting to single queue manager
- CCDT connecting to a single multi-instance queue manager
When using a message-driven bean (MDB) running within WebSphere Application Server to connect to a SINGLE multi-instance WebSphere MQ queue manager and use XA transactions, there are different options available:
1) Use a connection name list to specify the connection details for both the active and standby instances of a single multi-instance queue manager only.
2) Use a CCDT to define connection details to one, and only one, multi-instance queue manager that does NOT use queue manager groups.
This allows the standby queue manager to have knowledge of the transactions the previously active queue manager instance was involved in. As such the WAS Transaction Manager can coordinate transactional recovery as appropriate with this standby queue manager instance when it becomes active.
With APAR IV32387 applied, a CCDT may be used with queue manager groups. You can use a CCDT to define connection details to one, and only one, multi-instance queue manager. This is a queue manager group. This queue manager group will then be used if APAR IV32387 has been applied.
This APAR introduces a new Java system property that could be used to bypass the check on a queue manager name. Without APAR IV32387, using a CCDT with group manager groups (even if it only contains a single multi-instance queue manager entry) would fail as the group name would not match the name of the queue manager.
If APAR IV32387 were applied with the new Java system property set and you use a CCDT that contains entries only for a single multi-instance queue aliased by a queue manager group name, then the configuration would work.
However, if you desire to use a queue manager group which, in the future, will have additional queue manager definitions (multi-instance or otherwise) then the risks and issues concerning indoubt transactions will occur. In this case, should one of the scenarios described in APAR IV32387 occur, and an indoubt transaction remains on the Queue Manager, and the Transaction Manager has no knowledge of the transaction, then the WebSphere MQ Transaction must be completed manually by the WebSphere MQ administrator.
|Application Servers||WebSphere Application Server|
WebSphere MQ WMQ WebSphere Application Server WAS
More support for:
Software version: 7.0, 7.0.1, 7.1, 7.5
Operating system(s): AIX, HP-UX, Linux, Platform Independent, Solaris, Windows
Reference #: 1631879
Modified date: 25 March 2013