Introducing units of work
This topic introduces and defines the general concepts of unit of work, commit, backout and sync point. It also contains two scenarios that illustrate global units of work.
When a program puts messages on queues within a unit of work, those messages are made visible to other programs only when the program commits the unit of work. To commit a unit of work, all updates must be successful to preserve data integrity.
If the program detects an error and decides not to make the put operation permanent, it can back out the unit of work. When a program performs a backout, IBM MQ restores the queues by removing the messages that were put on the queues by that unit of work.
Similarly, when a program gets messages from one or more queues within a unit of work, those messages remain on the queues until the program commits the unit of work, but the messages are not available to be retrieved by other programs. The messages are permanently deleted from the queues when the program commits the unit of work. If the program backs out the unit of work, IBM MQ restores the queues by making the messages available to be retrieved by other programs.
The decision to commit or back out the changes is taken, in the simplest case, at the end of a task. However, it can be more useful for an application to synchronize data changes at other logical points within a task. These logical points are called sync points (or synchronization points) and the period of processing a set of updates between two sync points is called a unit of work. Several MQGET calls and MQPUT calls can be part of a single unit of work.
With IBM MQ, we need to distinguish between local and global units of work:
- Local units of work
- Are those in which the only actions are puts to, and gets from, IBM MQ queues, and the coordination of each unit of work is provided within the queue manager using a single-phase commit process.
Use local units of work when the only resources to be updated are the queues that are managed by a single IBM MQ queue manager. Updates are committed by using the MQCMIT verb or backed out using MQBACK.
There are no system administration tasks, other than log management, which is involved in using local units of work. In the applications, where we use the MQPUT and MQGET calls with MQCMIT and MQBACK, try using the MQPMO_SYNCPOINT and MQGMO_SYNCPOINT options. (For information about log management, see Manage log files.)
- Global units of work
- Are those in which other resources, such as tables in a relational database, are also updated. When more than one resource manager is involved, there is a need for transaction manager software that uses a two-phase commit process to coordinate the global unit of work.
Use global units of work when you also need to include updates to relational database manager software, such as Db2, Oracle, Sybase, and Informix .
There are several possible scenarios for using global units of work. Documented here are two scenarios:
- 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 ).
The following sections describe all the steps necessary to use global units of work, organized by the two scenarios:
- Scenario 1: Queue manager performs the coordination
- Scenario 2: Other software provides the coordination
Parent topic: Transactional support scenarios