How updates are coordinated across distributed systems

Db2 transaction manager support

Db2 supports a wide range of transaction manager products to coordinate updates across a distributed transaction. A distributed transaction typically involves multiple recoverable resources, such as Db2 tables, IBM® MQ messages, and IMS databases.

Db2 Connect clients support the X/OPEN Distributed Transaction Processing (DTP) model using the XA interface. The DTP model defines a standard architecture with three components: the application program that initiates transactions, the transaction manager that coordinates work across multiple systems, and resource managers, such as Db2, that manage data resources. The XA interface is the bidirectional communication protocol between the transaction manager and resource managers, enabling coordinated updates across a distributed transaction through a two-phase commit process. For more information about the XA specification, see Distributed TP: The XA Specification.

For application environments that do not use a transaction manager, Db2 coordinates updates across a distributed transaction by using DRDA-protected connections.

Servers that support two-phase commit

Updates in a two-phase commit situation are coordinated if they must all commit or all roll back in the same unit of work.

You can update an IMS database and a Db2 table in the same unit of work. Suppose that a system or communication failure occurs between committing the work on IMS and on Db2. In that case, the two programs restore the two systems to a consistent point when activity resumes.

Db2 coordinates commits even when a connection is using one-phase commit in a distributed transaction. In this case, however, only one location can perform an update.

Servers that do not support two-phase commit

In a distributed transaction, Db2 can coordinate a mixture of two-phase and one-phase connections.

You cannot have coordinated updates with a DBMS that does not implement two-phase commit. You can, however, achieve the effect of coordinated updates when you access a server that does not implement two-phase commit; such a server is called a restricted system.

Db2 prevents you from updating both a restricted system and any other system in the same unit of work. In this context, update includes the statements INSERT, DELETE, UPDATE, CREATE, ALTER, DROP, GRANT, REVOKE, and RENAME.

You can achieve the effect of coordinated updates with a restricted system. You must first update one system and commit that work, and then update the second system and commit its work. However, suppose that a failure occurs after the first update is committed and before the second update is committed. No automatic provision is available to bring the two systems back to a consistent point. Your program must handle that task.

When you access a mixture of systems, some of which might be restricted, you can take the following actions to ensure data integrity:

• Read from any of the systems at any time.
• Update any one system many times in one unit of work.
• Update many systems, including CICS or IMS, in one unit of work if no system is a restricted system. If the first system you update is not restricted, any attempt to update a restricted system within a unit of work results in an error.
• Update one restricted system in a unit of work. You can do this action only if you do not try to update any other system in the same unit of work. If the first system that you update is restricted, any attempt to update another system within that unit of work results in an error.