CORBA 2.3.3 Administration Guide (NonStop CORBA 2.3.3+)

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.
Resource Managers
The Transaction Service Specification describes a Resource Manager, which is the database(s) involved with a transaction.
NonStop CORBA supports two resource managers, NonStop SQL/MP and Enscribe. These resource managers are
responsible for making durable any changes required by a transaction commit.
In addition to these resource managers, the OTSTM uses NonStop TM/MP to interface with these resource managers.
Note
NonStop TM/MP is completely covered in the NonStop TM/MP documentation set. For detailed information on how to
administer NonStop TM/MP and how to recover from catastrophic events, refer to these documents.
Transaction Context
In a client/server scenario, a transaction typically begins when a client invokes a begin() operation. The client's request is
marshalled to a server object that is capable of handling the request. After all requests associated with a transaction have
returned, the client (also known as the transaction originator) can issue a request to complete the transaction.