CORBA 2.6.1 Administration Guide

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.
When a client initially begins the transaction, a transaction context is generated that is associated with the client thread. The transaction context
is the transaction information associated with a specific thread. The objects participating in the transaction use the transaction thread throughout
the lifespan of the transaction.
Propagating the Transaction Context
Transaction propagation refers to the act of associating the transaction context of a client with the operations performed by a transactional
object. In the Transaction Service Specification, two types of propagation are defined: implicit and explicit. Currently, only implicit propagation is
supported.
With implicit propagation, the transaction context associated with a request is automatically propagated by the ORB with the request; the server
handling the request “shares” the transaction context of the client. In this case, the transaction context is transmitted implicitly without direct
intervention from the client. This is different than explicit propagation, where the client directly passes the transaction context as a parameter to
the object server.
Controlling Transactions
The OMG Transaction Service Specification details two models with which you can control transactions:
Indirect context management uses the Current object to associate the transaction context with the application thread of control.
Direct context management uses the Control object along with other objects to control transactions.
NonStop CORBA applications typically use indirect context management, where the client uses the
CosTransactions::Current() interface to
create and control transactions. However, an application can also directly manage the transaction by accessing the
Control object (for example,
to resume a suspended transaction).
While NonStop CORBA also supports direct context management to make requests with respect to a particular transaction context, this method
of transaction control is strongly discouraged.
Application Portability
For an application to be portable across different CORBA-compliant Transaction Service implementations, the application should implement a
flat transaction model. In the flat model, the Transaction Service must treat all transactions as top-level transactions. They cannot have child (or
nested) transactions. By making use of a flat transaction model, NonStop CORBA server objects can participate in transactions invoked from a
foreign OTS.
Note:
The Transaction Service Specification includes references to both flat transactions and nested transaction, with
nested transaction being optional functionality. For the greatest range of portability, OTS supports only flat
transactions.
About This Guide Chapter 2. System Management