System and Application Softwares
X/Open Distributed Transaction Processing (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.
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.
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.
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.
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.
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.
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.
The Oracle XA library interface follows the two-phase commit protocol. The sequence of events is as follows:
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.
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.
When referring to XA, most organizations refer to version 1 of the XA specification. However a snapshot (draft) of version 2 was published in 1994 and is known as the XA+ specification, this was never ratified and formally published as a technical standard and is therefore not used by any of the key XA vendors. The XA+ specification was an enhanced specification that would enable distributed transactions to be coordinated across multiple heterogeneous Transaction Managers (e.g. Tuxedo and IBM Encina) as well as dictating how Transaction Managers should communicate with multiple RM instances (e.g. RAC).
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:
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:
© 2020 Digcode.com. All rights reserved.