Federated architecture for two-phase commit

Federated two-phase commit is based on the two-phase commit feature available in a database. In two-phase commit, the X/Open Distributed Transaction Processing (DTP) model has multiple components: transaction identifiers, transaction managers, and resource managers. In federated systems using federated two-phase commit, another component is added, the federated transaction manager.

A federated server becomes a federated transaction manager if the server coordinates activity for one or more remote data sources that use the two-phase commit protocol. A federated transaction manager performs some transaction management functions on behalf of the transaction manager. The client or application that initiates a distributed unit of work transaction and the transaction manager are unaware of the activity that the federated transaction manager coordinates at the remote data sources. The federated transaction manager communicates with database transaction managers using an XA interface. In addition to any X/Open requirements for two-phase commit, the transaction manager database must be accessible from the federated instance. Resource managers follow the instructions that are provided by a federated transaction manager to commit or roll back a transaction.

The following figure shows an example of a simple two-phase commit transaction in a typical federated system, from client initiation to the data source updates.

In the previous figure, the connection from the client to the transaction manager is a type 2 connection. Each database connection also has its own sync point setting. A sync point is a point in time when all the recoverable data that a program accesses is consistent. Sync point two-phase connections support distributed unit of work transactions with updates to multiple data sources.

When the client connects to the database, the transaction manager is aware of the transaction, but no additional coordination is required from the federated server. When the federated server connects to the data sources by using the two-phase commit protocol, the federated server becomes the federated transaction manager. The federated server monitors and coordinates the two-phase commits. At this point, the transaction manager is unaware of the two-phase commit transactions with the data sources. The transaction manager only knows that a single transaction is being processed with the federated server.

Data sources are not capable of initiating resynchronization if a failure occurs in a federated system. The federated server initiates the resynchronization process.

Results can be unpredictable if you attempt to access a data source by using multiple paths in the same transaction with federated two-phase commit. For example, if the federated server is a resource manager to an external transaction manager, the data source might be accessed indirectly from the federated server and directly as a resource manager to the transaction manager. In this case, the data source might not be able to tell whether these two paths are from the same global transaction. The data source might create two transaction entries for the same global transaction and treat each transaction as separate from the other, possibly leading to unpredictable results. The data source might also detect that the two paths are from the same global transaction, and reject the second path.