|
|
|
|
|
|
How the System Tracks Distributed Transaction Processing
BEA Tuxedo transactions can be used in a distributed architecture: a local machine involved in a transaction can communicate with a remote machine which may, in turn, communicate with another remote machine. The work of transactions executed in this type of arrangement is referred to as distributed transaction processing.
Because the system must constantly maintain enough information about a transaction to be able to roll it back (that is, to restore it to its initial state) at any moment, tracking distributed transaction processing (DTP) can be a complex task. To perform this task successfully, the BEA Tuxedo system stores tracking information about all the participants in a transaction in a dedicated file called a transaction log, or TLOG.
The following diagram shows an application in which two Transaction Managers (TMs) are being used. Both TMs record tracking data in the same TLOG.
Transaction Management
Before committing a transaction, the TM must repeatedly answer the question of whether to proceed. If necessary, the TM makes the decision to roll back.
How the System Uses Global Transaction Identifiers (GTRIDs) for Tracking
The BEA Tuxedo system tracks the flow of all transactions being executed within a distributed system, including those being executed concurrently. When it is time to commit a transaction, the coordinator must know which RMs have participated in the transaction and, therefore, needs to be able to distinguish among transactions. For this reason the BEA Tuxedo system assigns a global transaction identifier, or GTRID to each transaction.
The BEA Tuxedo system communicates with any RM accessed by an application through the XA interface. The RMs track transactions by assigning local transaction identifiers, and map global identifiers to local identifiers.
How the System Uses a Transaction Log (TLOG) for Tracking
A global transaction is recorded in the transaction log (TLOG) only when it is in the process of being committed. At the end of the first phase of a 2-phase-commit protocol, the TLOG records the reply from the global transaction participants.
The existence of a TLOG record indicates that a global transaction should be committed; no TLOG records are written for transactions that are to be rolled back.
In the first "pre-commit" phase, each Resource Manager must commit to performing the transaction request. If all parties commit, transaction management performs the second phase: it commits and completes the transaction. If either task fails because of an application or system failure, both tasks fail and the work performed is undone or "rolled back" to its initial state.
The TMS that coordinates global transactions uses the TLOG file. Each machine should have its own TLOG.
If you are using the Domains component in your application, keep in mind that the Domains gateway performs the functions of the TMS in Domains groups. However, Domains uses its own transaction log containing information similar to that recorded in the TLOG, in addition to Domains-specific information.
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|