Distributed Transactions Standards

Transactions Series Part 2

Some of the currently available standards are

• X/Open Distributed Transaction Processing Model
• OMG Object Transaction Service
• J2EE JTA and JTS
• Microsoft Transaction Server

X/Open Distributed Transaction Processing Model

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 four components -

• Application Programs to implement transactional operations.
• Resource Managers as discussed above.
• Transaction Managers as discussed above.
• Communication Resource Manager to facilitate interoperability between different transaction managers in different transaction processing domains.

This model has the following set of Interface APIs -

• TX Interface - This is an interface between the application program and the transaction manager, and is implemented by the transaction manager. This interface provides transaction demarcation services, by allowing the application programs to bound transactional operations within global transaction
• XA Interface - This 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. The second set of functions, called as ax_*() functions, are implemented by the transaction manager for use by resource managers
• XA+ Interface - This interface is used to support global transactions across different transaction manager domains via communication resource managers
• TXRPC Interface - This interface provides portability for communication between application programs within a global transaction
• CRM-OSI TP - An interface between a communication resource manager and the OSI transaction processing services

Some of the well known vendors compliant to this specification are IBM-Encina and BEA-Tuxedo

X/Open DTP components and Global Transaction

Though we previously identified four components, in principle, there are three components -

• AP - Application program
• RM - Resource Manager
• TM - Transaction Monotor

Application program is the actual application which is needing a distributed transaction. It needs to do a "unit of work" accessing distributed multiple shared resources each of which could do smaller atomic parts of the larger unit of work. In this context, the application program starts doing the "unit of work" which is referred to as the "Global Transaction" and to delineate this global transaction, from other work that it might be doing, informs the transaction monitor of the start of the global transaction and thus specifying the boundaries of the transaction.

Transaction Monitor's responsibility is to manage this global transaction in terms of its atomicity, isolation and durability. It does this by marking the global transaction with each of the participating resource managers using what is referred to as transaction branches which is identified by XID. Later, when the global transaction is completed, the transaction monitor also initiates competion and in case of any failures, initiates recovery.

The resource manager provides access to resources on which the application program performs work. The resource manager in this context does work for the application program and also works with the transaction monitor in completion of the global transaction. To identify multiple work that it may be doing for application programs and to keep it separate, it makes use of the "transaction context".

So, the idea here is that an application program needs to do work, which is constituted of multiple smaller pieces of work which are done by/on distributed shared resources on distributed resource managers. This piece of work is referred to as Global Transaction. For this global transaction to have the ACID properties, it is clear that no one resource manager can do the job, as there will be synchronization needed between the various resource managers. This is where the transaction monitor comes in. Transaction monitor now gives a definition to the global transaction when the application program initiates it on the transaction monitor, then keeps each of the resource manager in the transaction context when the application program is actually doing work thereby trying to achieve the necessary isolation, and finally when the application program specifies the completion of the work, it coordinates in ensuring that each
each of the individual pieces of work is durably and atomically made permanant by initiating the 2-phase commit and on successful preparation, taking care of any recovery if a failure occurs afterwards.

Transaction Branch and Thread of Control

Transaction branch is actually an atomic part of the global transaction that is being done by a resource manager. Each transaction branch is identified by an XID which is nothing but a structure which contains (1) format id (2) global transaction id length, (3) branch qualifier length and (4) actual data ID data.

Before the application program does any work on a resource, the transaction monitor will need to tell the resource manager that such a work is going to start, which it does by calling xa_start() API. This API feeds the resource manager with the XID which is unique to the transaction manager for all the transaction branches it is controlling. Once the XID is fed into the resource manager, the transaction monitor can in effect forget about the XID as its job is done. Typically, at this stage what happens is that the xa_start() implementation of the resource manager [which is linked into the application program] will make note of the XID in probably a thread local storage area and initializes its transaction context. There after, when work is being done by the application program on the resource manager, each time, the transaction context is sent across to the resource manager which then takes ownership of providing the necessary isolation for the transaction branch in the resouce manager.

So, the concept of thread of control is central to this whole architecture.

Please note that every thread of control which might want to act on the resource manager, will have to first own a XA connection to the resource manager. This connection is thread specific and cannot be shared between threads. Typically, this is done with a call to xa_open() and generally can happen at application start. When the application is done with all resource manager access, it can close this connection by calling xa_close().

When an application starts the transaction by calling tx_open(), transaction monitor will have to some how know which resource managers are going to be accessed by the application program. So, probably in the call to tx_open(), it might know which resource is being accessed and start the transaction branch with the resourc manager by calling xa_start(). At this point, the XID is sent to the resource manager, and it probably records the transaction context (which includes the XID) in the thread local storage of the thread of control. At this point, we say that the thread is associated with the transaction branch. A thread can have only a single association with a transaction branch. However, it may be associated with other transaction branches, which could be part of the same global transaction, but on other resource managers. Now, after this step, when the application program tries to make invocation on the resource manager to do work, the transaction context is implicitly propagated to the resource manager and hence it knows that the current work being performed is part of a specific transaction.

Another thread of control may also want to join this specific transaction branch by calling xa_start() again using a specific flag and the same XID. In this case, the second thread may wait till the first thread's association completes.

A thread of control may want to suspend its association with a transaction. It can then call xa_end() with a specific flag which will keep the association of the tranaction in a suspended state with respect to this specific thread. The thread may later resume the transaction context by calling xa_start() with a specific flag.

Once the thread of control is done with its work on the transaction branch, it can call xa_end() which will then terminate its association with the transaction branch. Please note that if it so needs it can later join the transaction branch again.

For a transaction branch to be completed, all threads of control should have broken their association with the branch. Only after this, can prepare be called.

Tightly and loosely coupled Threads of Control

This is also called Tightly and Loosely coupled Transaction Branches

When a multiple threads of control want to join the same transaction branch, the threads are said to be tightly coupled. The way this can happen is if all these threads use the same XID when calling xa_start(). In this scenario, the RM guarentees that from the perspective of isolation, it will see all these tightly coupled threads as the same entity. This means that half baked changes of one thread will be seen by the other. Also, the RM will need to guarentee that the threads will not deadlock on any resources in the branch. Typically, in this scenario what happens is that when a thread of control is having an active association, then when another thread tries to join, the second thread will have to wait till the first thread disassociates from the transaction branch.

Now, on the other hand, if the second thread used a different XID, it is actually starting up a new branch in the RM, but still part of the same global transaction. From the perspective of RM, the two branches are isolated from each other. This is called Loosely coupled threads of control.

From the perspective of concurrency, loosely coupled threads of control are more concurrent that the tightly coupled ones.

Dynamic Registration of Resource Managers

We have seen in the previous cases that a transaction branch gets created when xa_start() is called by the transaction monitor on the resource manager and typically, the transaction monitor does this for all RMs. Even if an RM is not involved in a branch, it gets registered. To avoud this overhead, resourc managers can register themselves with transaction monitors for completion only when the application actually accesses them. This is done using the ax_reg(). The only point to be noted here is that the resource manager needs to call ax_reg() from the application program's thread of control.

Also note that the transaction monitor will call xa_start() in the normal case only if the resource manager does not support automatic registration.
TX Interface

• tx_open - Opens the transaction manager and the set of associated resource managers
• tx_close - Closes the transaction manager and the set of associated resource managers
• tx_begin - Begins a new transaction
• tx_rollback - Rolls back the transaction
• tx_commit - Commits the transaction
• tx_set_commit_return - Commits the transaction
• tx_set_transaction_control - Switches between chained and unchained mode. In the case of chained transactions, the work is broken into pieces with each piece being under control of a flat transaction. Once a piece of work is complete it is committed or rolled back independent of the state of the other pieces
• tx_set_transaction_timeout - Sets a transaction timeout interval
• tx_info - Returns transaction information such as its identifier, state of the transaction etc

XA Interface

• 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

• ax_reg - Dynamically enlists with the transaction manager
• ax_unreg - Dynamically delists from the transaction manager

OMG Object Transaction Service

Object Transaction Service (OTS) is a distributed transaction processing service specified by the OMG. This specification extends CORBA model model and defines a set of interfaces to perform transaction processing across multiple CORBA objects.

The OTS model is based on the X/Open DTP model with the following enhancements -

• The OTS model replaces the functional XA and TX interfaces with CORBA IDL interfaces.
• The various objects in this model communicate via CORBA method calls over IIOP.

Interfaces

• Current - Responsibilities include Transaction demarcation (begin, commit, rollback, rollback_only, set_time_out) , Status of the transaction (get_status), Name of the transaction (get_transaction_name), Transaction context (get_control)
• TransactionFactory - Explicit transaction creation
• Control - Explicit transaction context management
• Terminator - Commit or rollback a transaction
• Coordinator - Status of the transaction (get_status, get_parent_status, get_top_level_status) , Transaction information (is_same_transaction, is_related_transaction, is_ancestor_transaction, is_descendant_transaction, is_top_level_transaction, hash_transaciton, hash_top_level_transaction, get_transaction_name, get_txcontext), Resource enlistment (register_resource, register_subtrans_aware) , Registration of synchronization objects (register_synchronization) , Set the transaction for rollback (rollback_only)
• RecoveryCoordinator - Coordinate recovery in case of failure (replay_completion)
• Resource - Participation in two-phase commit and recovery protocol (prepare, rollback, commit, commit_one_phase, forget)
• Synchronization - Application synchronization before beginning and after completion of two-phase commit (before_completion, after_completion)
• TransactionalObject - A marker interface to be implemented by all transactional objects

s