Transaction management and support
An introduction to transaction management and how IBM® MQ supports transactions.
- An IBM MQ queue manager, with resources that are its queues
- A Db2® database, with resources that are its tables
When an application updates the resources of one or more resource managers, there might be a business requirement to ensure that certain updates all complete successfully as a group, or none of them complete. The reason for this kind of requirement is that the business data would be left in an inconsistent state if some of these updates completed successfully, but others did not.
Updates to resources that are managed in this way are said to occur within a unit of work, or a transaction. An application program can group a set of updates into a unit of work.
During a unit of work, an application issues requests to resource managers to update their resources. The unit of work ends when the application issues a request to commit all the updates. Until the updates are committed, none of them become visible to other applications that are accessing the same resources. Alternatively, if the application decides that it cannot complete the unit of work for any reason, it can issue a request to back out all the updates it has requested up to that point. In this case, none of the updates ever become visible to other applications. These updates are usually logically related and must all be successful for data integrity to be preserved. If one update succeeds while another fails, data integrity is lost.
When a unit of work completes successfully, it is said to commit. Once committed, all updates made within that unit of work are made permanent and irreversible. However, if the unit of work fails, all updates are instead backed out. This process, where units of work are either committed or backed out with integrity, is known as sync point coordination.
The point in time when all the updates within a unit of work are either committed or backed out is called a sync point. An update within a unit of work is said to occur within sync point control. If an application requests an update that is outside of sync point control, the resource manager commits the update immediately, even if there is a unit of work in progress, and the update cannot be backed out later.
The computer subsystem that manages units of work is called a transaction manager, or a point coordinator.
A local unit of work is one in which the only resources updated are those of the IBM MQ queue manager. Here sync point coordination is provided by the queue manager itself using a single-phase commit process.
A global unit of work is one in which resources belonging to other resource managers, such as XA-compliant databases, are also updated. Here, a two-phase commit procedure must be used and the unit of work can be coordinated by the queue manager itself, or externally by another XA-compliant transaction manager such as IBM TXSeries®, or BEA Tuxedo.
A transaction manager is responsible for ensuring that all updates to resources within a unit of work complete successfully, or none of them complete. It is to a transaction manager that an application issues a request to commit or back out a unit of work. Examples of transaction managers are CICS® and WebSphere® Application Server, although both of these possess other function as well.
Some resource managers provide their own transaction management function. For example, an IBM MQ queue manager can manage units of work involving updates to its own resources and updates to Db2 tables. The queue manager does not need a separate transaction manager to perform this function, although one can be used if it is a user requirement. If a separate transaction manager is used, it is referred to as an external transaction manager.
For an external transaction manager to manage a unit of work, there must be a standard interface between the transaction manager and every resource manager that is participating in the unit of work. This interface allows the transaction manager and a resource manager to communicate with each other. One of these interfaces is the XA Interface, which is a standard interface supported by a number of transaction managers and resource managers. The XA Interface is published by The Open Group in Distributed Transaction Processing: The XA Specification.
- Phase 1 (Prepare to commit)
- The transaction manager asks each resource manager participating in the unit of work to ensure that all the information about the intended updates to its resources is in a recoverable state. A resource manager normally does this by writing the information to a log and ensuring that the information is written through to hard disk. Phase 1 completes when the transaction manager receives notification from each resource manager that the information about the intended updates to its resources is in a recoverable state.
- Phase 2 (Commit)
- When Phase 1 is complete, the transaction manager makes the irrevocable decision to commit the unit of work. It asks each resource manager participating in the unit of work to commit the updates to its resources. When a resource manager receives this request, it must commit the updates. It does not have the option to back them out at this stage. Phase 2 completes when the transaction manager receives notification from each resource manager that it has committed the updates to its resources.
For more information, see Transactional support scenarios.
IBM MQ also provides support for the Microsoft Transaction Server (COM+). Using the Microsoft Transaction Server (COM+) provides information on how to set up IBM MQ to take advantage of COM+ support.