![]() |
![]() |
|
|
How the System Uses a 2-Phase Commit to Commit Transactions
A 2-phase commit is an algorithm used to ensure the integrity of a committing transaction.
To understand how this algorithm works, consider the following sample scenario. A group of six friends wants to rent a house for a one-week vacation. No member of the group can afford to pay more than one sixth of the rent; if any of the six cannot participate, then the house cannot be rented.
A 2-phase transaction commit works in much the same way as the vacation planning project.
How the System Handles Transaction Infection
Any application module called by another module to participate in a transaction is said to be transactionally infected. Once an application module is infected, the BEA Tuxedo system tracks all participants to determine which of them should be involved in the 2-phase commit. The following figure shows how the system tracks participants.
Transactional Infection
In the preceding figure, Client 1 begins the transaction and calls three services: A, B, and C. Because they have been called into the transaction, Services A, B, and C are transactionally infected. All work performed by servers A, B, and C is part of the transaction begun by Client 1. All work is performed as one unit; either it is performed together and is successful, or it fails and is rolled back by calling tpabort. If the transaction fails, it returns to its initial state and its effects of the transaction on resource managers are undone. (Resource managers that are not transactionally aware and those that are accessed from outside the transaction cannot be rolled back.)
How the ATMI Protects a Transaction's Integrity Before a 2-Phase Commit
All work performed by each resource involved in a transaction must be completed before a 2-phase commit is begun. The ATMI ensures that all the work of the transaction is stopped when it is time for the 2-phase commit protocol to begin.
The following step-by-step description of a transaction shows how the ATMI stops a transaction process before a 2-phase commit.
If, during the transaction, an invoked service is performing another service, or is involved in an open conversation, the ATMI tracks that activity and prevents the application from proceeding to the commitment process until the activity is complete.
The ATMI guarantees that the transaction is committed only if all invoked services have performed their transaction work successfully. When all work has been performed successfully, the Transaction Manager informs the resource managers that all updates made during the transaction are permanent.
See Also
![]() |
![]() |
![]() |
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|