Object Transaction Service (OTS) is a distributed transaction processing
service specified by the Object Management Group (OMG). This specification
extends the CORBA model and defines a set of interfaces to perform transaction
processing across multiple CORBA objects.
OTS is based on the Open Group's DTP model and is designed so that
it can be implemented using a common kernel for both the OTS and Open Group
APIs. In addition to the functions defined by DTP, OTS contains enhancements
specifically designed to support the object environment. Nested transactions
and explicit propagation are two examples.
The CORBA model also makes some of the functions in DTP unnecessary
so these have been consciously omitted. Static registration and the communications
resource manager are unnecessary in the CORBA environment.
A key feature of OTS is its ability to share a common transaction with
XA compliant resource managers. This permits the incremental addition of
objects into an environment of existing procedural applications.
Figure 1 - OTS Architecture
The OTS architecture, shown in Figure 1, consists of the following components:
-
Transaction Client: A program or object that invokes operations
on transactional objects.
-
Transactional Object: A CORBA object that encapsulates or refers
to persistent data, and whose behavior depends on whether or not its operations
are invoked during a transaction.
-
Recoverable Object: A transactional object that directly maintains
persistent data, and participates in transaction protocols.
-
Transactional Server: A collection of one or more transactional
objects.
-
Recoverable Server: A collection of objects, of which at least one
of which is recoverable.
-
Resource Object: A resource object is an object in the transaction
service that is registered for participation in the two-phase commit and
recovery protocol.
In addition to the usual transactional semantics, the CORBA OTS provides
for the following features:
-
Nested Transactions: This allows an application to create a transaction
that is embedded in an existing transaction. In this model, multiple subtransactions
can be embedded recursively in a transaction. Subtransactions can be committed
or rolled back without committing or rolling back the parent transaction.
However, the results of a commit operation are contingent upon the commitment
of all the transaction's ancestors. The main advantage of this model is
that transactional operations can be controlled at a finer granularity.
The application will have an opportunity to correct or compensate for failures
at the subtransaction level, without actually attempting to commit the
complete parent transaction.
-
Application Synchronization: Using the OTS synchronization protocol,
certain objects can be registered with the transaction service for notification
before the start of and the completion of the two-phase commit process.
This enables such application objects to synchronize transient state and
data stored in persistent storage.
Application programming models
A client application program may use direct or indirect context management to
manage a transaction. With indirect context management, an application uses the
pseudo object called Current, provided by the Transaction Service , to associate
the transaction context with the application thread of control. In direct context
management, an application manipulates the Control object and the other objects
associated with the transaction.
An object may require transactions to be either explicitly or implicitly
propagated to its operations.
-
Explicit propagation means that an application propagates a transaction
context by passing objects defined by the Transaction Service as explicit
parameters. This should typically be the PropagationContext structure.
-
Implicit propagation means that requests are implicitly associated with
the client's transaction; they share the client's transaction context.
It is transmitted implicitly to the objects, without direct client intervention.
Implicit propagation depends on indirect context management, since it propagates
the transaction context associated with the Current pseudo object. An object
that supports implicit propagation would not typically expect to receive
any Transaction Service object as an explicit parameter.
A client may use one or both forms of context management, and may communicate
with objects that use either method of transaction propagation. (Details
of how to enable implicit propagation were described in Section Chapter
0 and Section 0). This results in four ways in which client applications
may communicate with transactional objects:
-
Direct Context Management/Explicit Propagation: the client application
directly accesses the Control object, and the other objects which describe
the state of the transaction. To propagate the transaction to an object,
the client must include the appropriate Transaction Service object as an
explicit parameter of an operation; typically this should be the PropagationContext
structure.
-
Indirect Context Management/Implicit Propagation: the client application
uses operations on the Current pseudo object to create and control its
transactions. When it issues requests on transactional objects, the transaction
context associated with the current thread is implicitly propagated to
the object.
-
Indirect Context Management/Explicit Propagation: for an implicit model
application to use explicit propagation, it can get access to the Control
using the get_control operation on the Current pseudo object. It can then
use a Transaction Service object as an explicit parameter to a transactional
object; for efficiency reasons this should be the PropagationContext structure,
obtained by calling get_txcontext on the appropriate Coordinator reference.
This is explicit propagation.
-
Direct Context Management/Implicit Propagation: a client that accesses
the Transaction Service objects directly can use the resume pseudo object
operation to set the implicit transaction context associated with its thread.
This allows the client to invoke operations of an object that requires
implicit propagation of the transaction context.
Examples
- Indirect and Implicit
In the code fragments below, a transaction originator uses indirect context
management and implicit transaction propagation; txn_crt is an example of
an object supporting the Current interface. The client uses the begin operation
to start the transaction whichbecomes implicitly associated with the originator's
thread of control.
...
txn_crt.begin();
// should test the exceptions that might be raised
...
// the client issues requests, some of which involve
// transactional objects;
BankAccount.makeDeposit(deposit);
...
txn_crt.commit(false)
The program commits the transaction associated with the client thread.
The report_heuristics argument is set to false so no report will be made
by the Transaction Service about possible heuristic decisions.
- Direct and Explicit
In the following example, a transaction originator uses direct context
management and explicit transaction propagation. The client uses a factory
object supporting the CosTransactions::TransactionFactory interface to create
a new transaction and uses the returned Control object to retrieve the Ter
mi nat or and Coordinator objects.
...
CosTransactions::Control ctrl;
CosTransactions::Terminator ter;
CosTransactions::Coordinator coo;
coo = TFactory.create(0);
ter = ctrl.get_terminator();
...
transactional_object.do_operation(arg, c);
...
t.commit(false);
The client issues requests, some of which involve transactional objects,
in this case explicit propagation of the context is used. The Control object
reference is passed as an explicit parameter of the request; it is declared
in the OMG IDL of the interface. The transaction originator uses the Terminator
object to commit the transaction; the report_heuristics argument is set
to false: so no report will be made by the Transaction Service about possible
heuristic decisions.
The main difference between direct and indirect context management is the effect
on the invoking thread's transaction context. If using indirect (i.e., invoking
operations through the Current pseudo object), then the thread's transaction
context will be modified automatically by the OTS, e.g., if begin is called
then the thread's notion of the current transaction will be modified to the
newly created transaction; when that is terminated, the transaction previously
associated with the thread (if any) will be restored as the thread's context
(assuming subtransactions are supported by the OTS implementation). However,
if using direct management, no changes to the threads transaction context are
performed by the OTS: the application programmer assumes responsibility for
this.
OTS Interfaces
Figure 2 describes the principal interfaces in the CORBA OTS specification,
with their interaction, while the Table 1 below provides more details for
each interface.
Figure 2 - OTS interfaces and their interactions
Table 1 - OTS Interfaces and their role.
Interface
|
Role and operations
|
Current |
-
Transaction demarcation (begin, commit, rollback, rollback_only, set_time_out)
-
Status of the transaction (get_status)
-
Name of the transaction (get_transaction_name)
-
Transaction context (get_control)
|
TransactionFactory |
Explicit transaction creation
-
create a transaction with its associated cooridinator (create)
-
create an interposed coordinator as a subrodinator in the transaction tree
(recreate)
|
Control |
Explicit transaction context management
-
access to the transaction coordinator (get_coordinator)
-
access to the transactions terminator (get_terminator)
|
Terminator |
Commit (commit) or rollback (rollback) a transaction in a direct transaction
management mode |
Coordinator |
-
Status of the transaction (get_status, get_parent_status, get_top_level_status)
-
Transaction information (is_same_transaction, is_related_transaction,
is_ancestor_transaction, is_descendant_transaction, is_top_level_transaction,
hash_transaciton, hash_top_level_transaction, get_transaction_name, get_txcontext)
-
Resource enlistment (register_resource, register_subtrans_aware)
-
Registration of synchronization objects (register_synchronization)
-
Set the transaction for rollback (rollback_only)
-
Create subtransactions (create_subtransaction)
|
RecoveryCoordinator |
Allows to coordinate recovery in case of failure (replay_completion) |
Resource |
Participation in two-phase commit and recovery protocol (prepare,
rollback, commit, commit_one_phase, forget) |
Synchronization |
Application synchronization before beginning and after completion of
two-phase commit (before_completion, after_completion) |
SubtransactionAwareResource |
Commit or rollback a subtransaction (commit_subtransaction, rollback_subtransaction)
|
TransactionalObject |
A marker interface to be implemented by all transactional objects (no
operation defined) |