Overview of transaction processing

This section provides an overview of transactions and how they are processed. It explains transactions, CORBA, the components of the CORBA Transaction Service, and the process for a basic transaction.

What are transactions in a distributed environment?

In a distributed objects world, a transaction is a unit of work composed of a set of operations on objects. A familiar example is transferring money from one bank account to another. The transfer is two separate actions—a debit from one account, and a credit to another—that comprise a single transaction.

Figure 2

Example of a transaction

In this scenario, which implements a flat transaction model, both actions must be completed for the desired result to be achieved. If Action 1 is completed, but Action 2 is not, the customer loses money. If Action 1 is not completed, but Action 2 is, the bank loses money. Therefore, flat transactions are an all-or-nothing proposition—either all steps of a transaction must complete, or none of the steps must complete.

Note

There is another type of transaction—a nested transaction—that does not require that all steps of a transaction are completed. However, VisiTransact Transaction Manager does not support nested transactions.

Many things can happen to prevent all steps of a transaction from completing such as application logic, server failure, hardware failure, and network interruptions. Because of these unpredictable environment factors, transactions must adhere to the following properties, called ACID properties, to ensure the consistency, reliability, and integrity of applications:

•	Atomicity. If a transaction is completed successfully (it commits) all of the actions associated with the transaction are performed. Otherwise, if the transaction is not completed successfully, none of the actions are performed and the transaction is rolled back.

•

Consistency. All actions that comprise a transaction must be performed accurately so that the system moves from one consistent state to another. In the bank example, this means that the total money in both accounts before the transaction begins is the same as the total money in both accounts after the transaction completes.

•	Isolation. This means that intermediate results performed by a transaction are not visible outside the transaction until the entire transaction completes.

•	Durability. The results of a transaction are persistent.

Transactions do not always involve the transfer of funds as in the banking example we have just covered. Transactions are necessary for all sorts of business activities. For example, an online bookstore needs transactions to perform many activities including: ordering books from suppliers, transferring inventory from suppliers, updating available quantities of books accurately, charging customers appropriately for purchases, and fulfilling customer orders. All of these actions, and a multitude of others, may need to be executed within a transaction.

What is CORBA?

The Common Object Request Broker Architecture (CORBA) specification was adopted by the Object Management Group (OMG) to ensure a common approach to implementing and managing distributed objects. CORBA uses an object-oriented approach for creating software components that can be reused and shared between applications. Each object encapsulates the details of its inner workings and presents a well defined interface, which reduces application complexity. The cost of developing applications is also reduced, because once an object is implemented and tested, it can be used over and over again.

What is the CORBA Transaction Service?

The CORBA Transaction Service, defined by the OMG, enables mission-critical applications in distributed environments by providing transactional integrity. It defines IDL interfaces that allow multiple distributed objects to participate in a transaction, and enable a distributed application to handle transaction completion over the Internet and intranets.

Micro Focus’s implementation of the CORBA Transaction Service is embodied in the VisiTransact Transaction Service, a component of the Transaction Management architecture.

Model for a basic transaction

The VisiTransact Transaction Service can be used to manage the completion of a transaction. It works with objects at the ORB level to coordinate and manage a transaction's commit or rollback. The ORB enables the VisiTransact Transaction Service to propagate the transaction context to each object participating in the transaction. To accomplish this, the VisiTransact Transaction Service interfaces with participants of the transaction at specific points in the transaction management process.

In a distributed application, a transaction can involve multiple objects performing multiple requests. The objects that are involved can play a number of different roles. For example, an object that begins a transaction is called the transaction originator. The following table provides descriptions of these roles.

Role of Participant	Description
Transactional Client	A transactional client is the user's interface to a transactional application. Sometimes the transactional client is also the transaction originator.
Transaction Originator	A transaction originator is the object that begins a transaction. A transaction originator is not necessarily a transactional client—it might be a transactional server that originates a transaction.
Transactional Object	A transactional object is an object whose behavior is affected by the transaction, but has no recoverable state of its own. Although a transactional object does not participate in the completion of a transaction, it can force the transaction to rollback. See “Coordinating transaction completion with Resource objects” for information about recoverable objects, or objects whose recoverable state is affected by the transaction.
Transactional Server	A transactional server is a collection of one or more transactional objects.

The VisiTransact Transaction Service interacts with an application when the transaction originator begins the transaction, as transactional information is propagated to transactional objects, and finally, coordinates the transaction's completion (commit or rollback) across multiple objects.

Although this chapter does not address it, most transactions involve persistent data (such as databases). For these types of transactions, there are two additional participant roles—Resource and Recoverable Server. These roles are discussed in “Coordinating transaction completion with Resource objects”.

Beginning the transaction

When an object initiates a transaction, an instance of the VisiTransact Transaction Service begins a transaction for a transaction originator and establishes a transaction context. The transaction context is then associated with the originator's thread of control that was issued by the VisiBroker ORB. The transaction context contains transaction information, including an object transaction identifier (OTRID) that uniquely identifies the transaction.

Figure 3

Beginning the transaction

In step 1 of the figure above, the transaction originator registers with the VisiTransact Transaction Service its desire to begin a transaction. The VisiTransact Transaction Service answers this request with step 2 by returning a transaction context to the transaction originator.

Issuing requests to transactional objects

As the transaction originator issues requests to transactional objects in Step 3, each of these requests is also associated with the transaction context. Using the ORB, the VisiTransact Transaction Service propagates the transaction context to all objects participating in the transaction.

Figure 4

Issuing requests to transactional objects and passing the transaction context

Note

The transaction context is passed as a Service Context in the GIOP request and response headers. This makes its propagation completely transparent, and is compliant with the CORBAservices specification for interoperability between Transaction Service implementations.

Completing a transaction

A transaction can be completed in the following ways:

•	The transaction originator commits the transaction. This is the typical scenario.

•	Any component in the application, as long as Current is not used, can complete the transaction.

•	The transaction times out.

If a commit is requested and all participating Resources agree to commit, then the changes are committed. If any participant votes for rollback, then the transaction is rolled back.

If completion is not requested by the application, the VisiTransact Transaction Service will rollback the transaction when the timeout period expires.

Figure 5

Completing the transaction