Units of work allow multiple actions performed by an application to be grouped together so that any individual action within that unit of work can only complete successfully if all actions within that unit of work complete successfully. The basic construct that allows actions within a unit of work to complete or fail as a group is a transaction. The terms transaction and unit of work are often used interchangeably.
Units of work that include MQ actions and actions on other resources are called global units of work.
The transaction that controls a global unit of work is coordinated by a transaction manager, which must be able to communicate with all participants within that unit of work. The participants within a global unit of work are called resource managers.
MQ can act as the transaction manager coordinating global units of work that include database products as resource managers.
IBM only supports the operation of MQ as a transaction manager with certain resource managers. Also, IBM only supports the operation of MQ as a resource manager with certain transaction managers. See details
List of supported databases when MQ is under Solaris environment : DB2, Oracle, Sybase, Informix. [URL]
We define two scenarios for global units of work:
- In the first, the queue manager itself acts as the transaction manager. In this scenario, MQI verbs control the global units of work; they are started in applications using the MQBEGIN verb and then committed using MQCMIT or backed out using MQBACK.
- In the second, the transaction manager role is performed by other software, such as TXSeries, Encina, or Tuxedo. In this scenario, an API provided by the transaction manager software is used to control the unit of work (for example, EXEC CICS SYNCPOINT for TXSeries).
Sys Admin Guide, pg 174.
In general, a global unit of work is implemented in an application by the following method (in pseudocode):
As far as your application is concerned, the queue manager performs two roles: a resource manager (where the resources are messages on queues) and the transaction manager for the global unit of work.
Sys Admin Guide, pg 175.
The switch load file is a shared library (a DLL on Windows systems) that is loaded by the code in your MQ application and the queue manager. Its purpose is to simplify the loading of the database's client shared library, and to return the pointers to the XA functions.
MQ comes with a sample makefile, used to build switch load files for the supported database managers. The sample source modules used to build the switch load files are:
- For DB2, db2swit.c
- For Oracle, oraswit.c
- For Informix, infswit.c
- For Sybase, sybswit.c
When you have created a switch load file for your database manager, and placed it in a safe location, you must specify that location to your queue manager.
While a database manager is unavailable, you can use the dspmqtrn command to check the state of outstanding global units of work involving that database. The dspmqtrn command displays only those units of work in which one or more participants are in doubt, awaiting the decision from the queue manager to commit or roll back the prepared updates.
See rsvmqtrn.
Do the following:
- Check the environment variable settings
- Create the DB2 switch load file
- Add resource manager configuration information
- Change DB2 configuration parameters if necessary
You must always set the DB2INSTANCE environment variable before you start the queue manager.
Win :
Unix :
On Windows and Linux (x86 platform) systems use the WebSphere MQ Explorer.
Specify the details of the switch load file
in the queue manager properties panel, under XA resource manager.
On all other systems specify the details of the switch load file
in the XAResourceManager stanza in the queue manager's qm.ini file.
MQ v7 Sys Admin Guide, pg 169.
- Set database privileges
- Change the tp_mon_name parameter
- Reset the maxappls parameter
Sys Admin Guide, pg 183.
Coordination must be performed between all of the participants within a global unit of work to allow any resource manager to report a failure at any time. The most important form of coordination is called two-phase commit.
4.5.7, MQ v 6.0 Fundamentals, pg 64 [88/446]
The Open Group publishes the XA Specification : Distributed Transaction Processing: the XA Specification : URL This defines the interactions that can occur between a transaction manager and resource managers. MQ conforms to this specification.
MQ v6 Application Programming Guide.
- CICS
- IMS
- Encina
- Tuxedo
- WAS (?)
A single qmgr can coordinate a transaction between ITSELF
and any number of local or remote databases
- assuming that the database is supported
and the necessary configuration is done
to establish XA coordination with that database.
MQ does no transaction coordination
between more than ONE queue manager.
