CORBA 2.3.3 Administration Guide (NonStop CORBA 2.3.7+)

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.
Prev Up Next
About This Guide Home Chapter 2. System Structure