The X/Open Distributed Transaction Processing (DTP) model is a distributed
transaction processing model proposed by the Open Group, a vendor consortium.
This model is a standard among most of the commercial vendors in transaction
processing and database domains.
This model consists of the follwng components (illustrated in Figure 1)
-
an Application Program (AP), which defines transaction boundaries and specifies
actions that constitute a transaction
-
Resource Managers (RMs) such as databases or file access systems, which
provide access to resources
-
a Transaction Manager (TM), which assigns identifiers to transactions,
monitors their progress, and takes responsibility for transaction completion
and for coordinating failure recovery
-
Communication Resource Managers (CRMs), which control communication between
distributed applications within or across TM domains
Figure 1 - The X/Open DTP model
Interface between functional components
There are six interfaces between software components in the X/Open DTP model.
-
AP-RM. The AP-RM interfaces give the AP access to resources. X/Open interfaces,
such as SQL and ISAM provide AP portability. The X/Open DTP model imposes
few constraints on native RM APIs. The constraints involve only those native
RM interfaces that define transactions.
-
AP-TM. The AP-TM interface (the TX interface) provides the AP with an Application
Programming Interface (API) by which the AP coordinates global transaction
management with the TM. For example, when the AP calls tx_begin( ) the
TM informs the participating RMs of the start of a global transaction.
After each request is completed, the TM provides a return value to the
AP reporting back the success or otherwise of the TX call.
-
TM-RM. The TM-RM interface (the XA interface) lets the TM structure the
work of RMs into global transactions and coordinate completion or recovery.
The XA interface is the bidirectional interface between the TM and RM.
The functions that each RM provides for the TM are called the xa_*()
functions. For example the TM calls xa_start( ) in each participating
RM to start an RM-internal transaction as part of a new global transaction.
Later, the TM may call in sequence xa_end() xa_prepare( ) and xa_commit()
to coordinate a (successful in this case) two-phase commit protocol.
The functions that the TM provides for each RM are called the ax_*( ) functions.
For example an RM calls ax_reg( ) to register dynamically with the TM.
-
TM-CRM. The TM-CRM interface (the XA+ interface) supports global transaction
information flow across TM Domains. In particular TMs can instruct CRMs
by use of xa_*() function calls to suspend or complete transaction branches,
and to propagate global transaction commitment protocols to other transaction
branches. CRMs pass information to TMs in subordinate branches by use of
ax_*( ) function calls. CRMs also use ax_*( ) function calls to request
the TM to create subordinate transaction branches, to save and retrieve
recovery information, and to inform the TM of the start and end of blocking
conditions.
-
AP-CRM. X/Open provides portable APIs for DTP communication between APs
within a global transaction. The API chosen can significantly influence
(and may indeed be fundamental to) the whole architecture of the application.
For this reason, these APIs are frequently referred to in this specification
and elsewhere as communication paradigms.In practice, each paradigm has
unique strengths, so X/Open offers the following popular paradigms:
-
the TxRPC interface (see the referenced TxRPC specification)
-
the XATMI interface (see the referenced XATMI specification)
-
the CPI-C interface (see the referenced CPI-C specification).
X/Open interfaces, such as the CRM APIs listed above, provide application
portability. The X/Open DTP model imposes few constraints on native CRM
APIs.
-
CRM-OSI TP. This interface (the XAP-TP interface) provides a programming
interface between a CRM and Open Systems Interconnection Distributed Transaction
Processing (OSI TP) services. XAP-TP interfaces with the OSI TP Service
and the Presentation Layer of the seven-layer OSI model. X/Open has defined
this interface to support portable implementations of application-specific
OSI services. The use of OSI TP is mandatory for communication between
heterogeneous TM domains. For details of this interface, see the referenced
XAP-TP specification and the OSI TP standards.
Although the aim of the Open Group was providing portable interfaces, only
the XA interface appears to be accepted and implemented by a wide
range of vendors.
XA is a bidirectional interface between resource managers and transaction
managers. This interface specifies two sets of functions. The first set,
called as xa_*() functions are implemented by resource managers for use
by the transaction manager.
Table 1 - XA Interface of X/Open DTP Model for the transaction manager
Function
|
Purpose
|
xa_start |
Directs a resource manager to associate the subsequent requests by
application programs to a transaction identified by the supplied identifier. |
xa_end |
Ends the association of a resource manager with the transaction. |
xa_prepare |
Prepares the resource manager for the commit operation. Issued by the
transaction manager in the first phase of the two-phase commit operation. |
xa_commit |
Commits the transactional operations. Issued by the transaction manager
in the second phase of the two-phase commit operation. |
xa_recover |
Retrieves a list of prepared and heuristically committed or heuristically
rolled back transactions |
xa_forget |
Forgets the heuristic transaction associated with the given transaction
identifier |
The second set of functions, called as ax_*() functions, are implemented
by the transaction manager for use by resource managers.
Table 2 - XA Interface of X/Open DTP Model for resource managers
Function
|
Purpose
|
ax_reg() |
Dynamically enlists with the transaction manager. |
ax_unreg() |
Dynamically delists from the transaction manager. |