Tuxedo as a Transaction Processing Monitor › Applications with Transaction Control: XA-based Tuxedo Servers › Two Phase Commit › X/Open Distributed Transaction Processing

X/Open Distributed Transaction Processing

The X/Open Distributed Transaction Processing (DTP) model defines the following separate entities that participate in a distributed application:

• Application Program (AP)
• Transaction Manager (TM)
• Resource Manager (RM)

The following illustration shows the relationships between these three entities:

The AP is the CA Gen server application code and it issues transactional statements to the RM. The TM is the Transaction Manager responsible for managing transactions on behalf of the application. The RM is the Resource Manager that typically is a database but can be any resource that needs management, such as a print spooler or a queue.

The interfaces between these components are defined in the X/Open DTP specification.

• The interface between the AP and RM is generally SQL, and no specification is given for this interface. At server startup, all application servers and Transaction Management Servers (TMSs) open a connection to the RM through the XA API xa_open(). This establishes a connection to the RM for global transactions. Conversely, at server shutdown the connection is closed by the XA API xa_close(). These XA APIs are managed through the Tuxedo APIs tpopen()/tpclose() which the AP invokes.
• The interface between the TM and RM is managed by Tuxedo. There are many procedural interfaces defined for XA compliant RMs (for example, xa_open(), xa_start(), xa_end(), xa_prepare(), xa_commit(), and xa_recover()). It is through these interfaces that the TM communicates with the RM, on behalf of the AP.
• The interface between the AP and TM is mainly through the Tuxedo transactional APIs tpbegin(), tpcommit() and tpabort(). One of the roles of the TM is to allocate a unique global transaction identifier, or XID. The XID is carried in every service call request made in this global transaction context. In this way, multiple services and servers can participate in the same global transaction. The various servers can belong to the same TMS group or to a different TMS group (for example, one server can belong to an Oracle TMS group while another server can belong to a TMS group). In each case, it is the responsibility of the RM to associate work for the same XID. When a request to commit is sent to the TMS the TMS begins the two phase commit process.