X/Open Distributed Transaction Processing (DTP) Model

Possible DTP Model

Within the X/Open DTP model the AP will communicate to the RM using the RM’s native interface (e.g. SQL) for all DML. The AP will also communicate to the TM using the TX protocol to demarcate transaction boundaries. The TX protocol has a number of “standard” implementations, namely XATMI (Tuxedo based), TxRPC (DCE based) and XCPI-C (IBM Encina based). Not all of these implementations are supported by all TMs e.g. Tuxedo only supports the XATMI and TxRPC standards, whereas IBM Encina only supports the TxRPC and XCPI-C standards. The TM will communicate to all the RMs using the XA protocol to co-ordinate a two-phase commit.

Some products such as the Oracle database and Oracle WebLogic Server can act as either Transaction Managers or Resource Managers or both within the same XA transaction.

Application Program (AP)

An application program defines transaction boundaries and specifies actions that constitute a transaction. For example, an AP can be a precompiler or OCI program. The AP operates on the RM's resource through its native interface, for example, SQL.

Resource Manager (RM)

A resource manager controls a shared, recoverable resource that can be returned to a consistent state after a failure. Examples are relational databases, transactional queues, and transactional file systems. Oracle Database is an RM and uses its online redo log and undo segments to return to a consistent state after a failure.

Transaction Manager (TM)

A transaction manager provides an API for specifying the boundaries of the transaction and manages commit and recovery. The TM implements a two-phase commit engine to provide "all-or-none" semantics across distributed RMs.

An external TM is a middle-tier component that resides outside Oracle Database. Normally, the database is its own internal TM. Using a standards-based TM enables Oracle Database to cooperate with other heterogeneous RMs in a single transaction.

Transaction Processing Monitor (TPM)

A TM is usually provided by a transaction processing monitor (TPM) vendor. A TPM coordinates the flow of transaction requests between the client processes that issue requests and the back-end servers that process them. Basically, a TPM coordinates transactions that require the services of several different types of back-end processes, such as application servers and RMs distributed over a network.

The TPM synchronizes any commits or rollbacks required to complete a distributed transaction. The TM portion of the TPM is responsible for controlling when distributed commits and rollbacks take place. Thus, if a distributed application program takes advantage of a TPM, then the TM portion of the TPM is responsible for controlling the two-phase commit protocol. The RMs enable the TMs to perform this task.

Because the TM controls distributed commits or rollbacks, it must communicate directly with Oracle Database (or any other RM) through the XA interface. It uses Oracle XA library subroutines, which are described in Oracle XA Library Subroutines, to tell Oracle Database how to process the transaction, based on its knowledge of all RMs in the transaction.

Distributed Transaction

A distributed transaction, also called a global transaction, is a client transaction that involves updates to multiple distributed resources and requires "all-or-none" semantics across distributed RMs.

Branch

A branch is a unit of work contained within one RM. Multiple branches make up one global transaction. In the case of Oracle Database, each branch maps to a local transaction inside the database server.

Two-Phase Commit Protocol

The Oracle XA library interface follows the two-phase commit protocol. The sequence of events is as follows:

• In the prepare phase, the TM asks each RM to guarantee that it can commit any part of the transaction. If this is possible, then the RM records its prepared state and replies affirmatively to the TM. If it is not possible, then the RM might roll back any work, reply negatively to the TM, and forget about the transaction. The protocol allows the application, or any RM, to roll back the transaction unilaterally until the prepare phase completes.
• In phase two, the TM records the commit decision and issues a commit or rollback to all RMs participating in the transaction. TM can issue a commit for an RM only if all RMs have replied affirmatively to phase one.

TX Interface

An application program starts and completes all transaction control operations through the TM through an interface called TX. The AP does not directly use the XA interface. APs are not aware of branches that fork in the middle-tier: application threads do not explicitly join, leave, suspend, and resume branch work, instead the TM portion of the transaction processing monitor manages the branches of a global transaction for APs. Ultimately, APs call the TM to commit all-or-none.

Tight and Loose Coupling

Application threads are tightly coupled if the RM considers them as a single entity for all isolation semantic purposes. Tightly coupled branches must see changes in each other. Furthermore, an external client must either see all changes of a tightly coupled set or none of the changes. If application threads are not tightly coupled, then they are loosely coupled.

 

Transaction Managers and Resource managers that follow this specification are said to be XA compliant. Some products such as the Oracle database and Oracle WebLogic Server can act as either Transaction Managers or Resource Managers or both within the same XA transaction.

Examples of an XA Transaction Manager are: Tuxedo, Oracle WebLogic Server, the Oracle database and IBM WebSphere Application Server.

Examples of an XA Resource Manager are: Oracle Database, IBM DB2, MS-SQL, IBM MQ-Series and JMS.

Within XA, the TM co-ordinates all branches of a distributed transaction as well as maintaining state information on all distributed transactions within its control. If this state information is lost or becomes unavailable, then the underlying RMs may require manual intervention to resolve any indoubt transactions.

As the TM is responsible for coordinating and monitoring the progress of a distributed transaction, the application program MUST NOT contain any RM specific statements that will independently rollback or commit a distributed transaction. Therefore the application program MUST NOT issue any DDL (e.g. TRUNCATE, CREATE TABLE etc) as DDL is itself an implicit self-contained transaction. Always refer to the RM’s manuals to find out as to which statements are specifically allowed.

The XA two-phase commit mechanism has the following distinct phases, which the TM and RMs perform automatically whenever an application program commits a distributed transaction:

• Prepare phase: The TM asks participating RMs to promise to commit (or rollback) the transaction as requested, even if there is a failure. If any RM cannot prepare, the transaction is rolled back.
• Commit phase: If all RMs respond to the TM that they are prepared, then the TM asks all RMs to commit the transaction.

XA supports both the “Read Only” and “Single Phase” optimizations.

Within an XA distributed transaction there are a least two or more transaction branches that will perform work against one or more RMs. Within a single RM, these branches can be related whereby the relationship between any pair of participating branches is either tightly-coupled or loosely-coupled. If the transaction branches are tightly coupled, then they share locks. Consequently for tightly coupled transactions, pre-commit updates made in one transaction branch will be visible in other branches that belong to the same distributed transaction. In loosely coupled transaction branches, the branches do
not share locks and do not see updates in other branches.

Tightly coupled transactions require the RM to guarantee that resource deadlock will not occur between individual branches of an XA transaction. The way that this is implemented is at the discretion of the RM, but it can have the effect of limiting concurrent data access across all tightly coupled branches. (e.g. only one branch can be actively using DML at a time).

The XA standard allows for heuristic completion of one or more transaction branches within a distributed transaction. If a communication failure occurs, some RMs may employ heuristic decision making to decide whether a prepared transaction is committed or rolled back independently of the TM. For example this could be to unlock shared resources, however this may leave the data in an inconsistent state with regards to the rest of the distributed transaction, e.g. if an RM commits it’s
branch but all other branches are asked to rollback, then the result will be inconsistent across all RMs. Alternatively there may have been manual intervention (e.g. by a DBA or system administrator) to release locks, which again results in Heuristic completion of a distributed transaction. Note that if an RM that reports heuristic completion to the TM, the RM must not discard its knowledge of the transaction branch, this often means that although the outcome of the distributed transaction has been
resolved manually, references to the heuristic transaction may still remain within the RM until manually removed.

The XA standard also allows for both synchronous and asynchronous modes of working. The asynchronous mode is optional and NOT supported by the Oracle database.

Unlike Oracle-controlled distributed transactions, the XA specification does not allow a 'point in time' marker to be agreed between participating databases (e.g. an equivalent to the SCN synchronization discussed in Oracle-controlled distributed transactions above). This means that if an incomplete recovery of one or more RMs is required, there is NO mechanism of bringing all RMs to the same transactionally consistent point in time. For incomplete recovery there are two options:

• Design an application specific recovery mechanism to ensure transactional consistency across all RMs is maintained in the event of an incomplete recovery being performed;
• A point in time recovery is performed to a point where there was little or no activity on the RMs (e.g. from a cold backup or recovery to a point where the application was quiesed). My Oracle Support Note 52776.1 Determining a Point In Time for Incomplete Recovery under XA, describes a mechanism for identifying when to perform incomplete recovery within Oracle.