Commit coordinator and multiple participants

The principles and methods for maintaining consistency across more than two systems are similar to those that are used to ensure consistency across two systems. The main difference involves the role of a system as coordinator or participant when a unit of work spans multiple systems.

The coordinator of a unit of work that involves two or more other DBMSs must ensure that all systems remain consistent. After the first phase of the two-phase commit process, the Db2 coordinator waits for the other participants to indicate that they can commit the unit of work. If all systems are able, the Db2 coordinator sends the commit decision and each system commits the unit of work.

If even one system indicates that it cannot commit, the Db2 coordinator communicates the decision to roll back the unit of work at all systems. This process ensures that data among multiple DBMSs remains consistent. When Db2 is the participant, it follows the decision of the coordinator, whether the coordinator is another Db2 or another DBMS.

Db2 is always the participant when interacting with IMS, CICS®, or WebSphere Application Server systems. However, Db2 can also serve as the coordinator for other DBMSs or for other Db2 subsystems in the same unit of work. For example, if Db2 receives a request from a coordinating system that also requires data manipulation on another system, Db2 propagates the unit of work to the other system and serves as the coordinator for that system.

In the following figure, DB2A is the participant for an IMS transaction, but Db2 becomes the coordinator for the two database servers (AS1 and AS2), for DB2B, and for its respective Db2 servers (DB2C, DB2D, and DB2E).

Figure 1. Illustration of multi-site unit of work
Begin figure description. This figure is a diagram that depicts a network of database servers. End figure description.

If the connection between DB2A and the coordinating IMS system fails, the connection becomes an indoubt thread. However, DB2A connections to the other systems are still waiting and are not considered indoubt. Automatic recovery occurs to resolve the indoubt thread. When the thread is recovered, the unit of work commits or rolls back, and this action is propagated to the other systems that are involved in the unit of work.