CORBA 2.6.1 Administration Guide

A transaction is a unit of work that behaves in accordance with the ACID properties that have become synonymous with transaction processing.
In transactions that are distributed across one or more systems, a Transaction Manager is normally relied upon to carry out the low-level details
involved in orchestrating a transaction. By assuring the ACID properties outlined below, a Transaction Manager can ensure that its transaction
processing is secure and reliable:
Atomic
A transaction is atomic when it either commits all individual changes made by the transaction or rolls back any changes the transaction
produced. A transaction must be an “all or nothing” procedure.
Consistent
A transaction must take the system from one consistent state to another. In doing so, the transaction must preserve the invariant
properties of the system.
Isolated
The “unit of work” performed by a transaction must be hidden from other entities accessing the system while the work is being carried
out. The intermediate states of a transaction must not be visible to other transactions or to other objects that access the data on which
the transaction is working. Transactions appear to execute serially, even if they are performed concurrently.
Durable
No effects of a completed, committed transaction can be lost; they must all be persistently stored.
With this, a transaction is a series of operations that takes a system from one consistent state to another.
Transactional Objects
The OMG Transactional Service Specification defines a transactional object as an object whose behavior is affected by being invoked within the
scope of a transaction. A transaction object typically contains or indirectly references persistent data that can be modified by a request made
within the scope of a transaction.
Transactional Clients
A client can make requests of any mix of transactional and nontransactional objects. However, if a client application makes any request within
the scope of a transaction, it is termed a transactional client.
Transaction Manager (OTSTM)
The OTSTM is a server-pool process that is installed and configured to run under the PATHMON process that runs the other system processes.
The OTSTM assures that the
ACID properties of a transaction are kept in check throughout the processing of the transaction. The OTSTM works
in concert with NonStop TM/MP, orchestrating the
two-phase commit protocol, which insures the integrity of all transaction data during the
termination of the transaction.
The OTSTM depends heavily on the interfaces defined in the transaction service.
Two-Phase Commit Process
The OTSTM uses a two-phase commit process to ensure that each transaction maintains the ACID characteristics associated with transaction
processing.
To understand the workings of a two-phase commit, it is helpful to first understand the processing of a rollback operation.
When a transaction terminates, all participants associated with the transaction must either commit or roll back. If, while processing a transaction,
a transaction participant finds that it must roll back the transaction, it issues a rollback. The OTSTM handles this request by invoking the roll
back call on each transaction participant associated with that transaction thread.
The process used to commit a transaction is similar to the roll back process described above. However, committing a transaction involves two
steps, or “phases”.
The first phase occurs when all objects invoked to do work in the scope of the transaction return from their calls. At this point, all transaction
participants establish a state from which they can either make any transaction modifications invisible or undo their share of the transaction work.
When all outstanding transaction operations return, the client invokes a
commit() operation. To handle this request, the OTSTM issues a
prepare() operation to all participants associated with the transaction.
The
prepare() essentially polls each participant, asking if they are ready to commit the transaction by making all transaction changes durable.
Here, each participant in the transaction must vote on whether the overall outcome of the transaction is to commit or rollback.
Based on the responses received from the first phase, the OTSTM begins the second phase of the commit protocol. If all transaction participants
voted to commit the transaction, the OTSTM terminates the transaction by calling the
commit() operation on each participant. It is after this call
that all changes made in effect of the transaction are made durable.
However, if even a single transaction participant indicates (votes) that it cannot commit, the OTSTM will invoke the rollback() operation on all
participants associated with the transaction. This effectively aborts any modifications that may have been made in effect of the transaction
processing.
Checked Behavior
The OTSTM also implements a checked transaction behavior, which provides an extra level of transaction integrity. Checked behavior ensures
that all client transactional operations have been successfully completed before the transaction can be committed. With the checked behavior,
the Transaction service can guarantee that a commit will not succeed unless all of the transactional objects involved in the transaction have
completed processing their transactional requests.