www.arjuna.com news company products standards research library forums contact
Trail map 1. Installation Content 2. The Sample Application 3. Deploying and Testing the Sample Application 4. Making the Sample Application Persistent 5. Recovery From Failure 6. Where Next? Navigation Home Additional Trails Distributed Transaction Processing The X/Open DTP Model The OMG OTS Model Transactions in J2EE Configuring ATS Configuring the Recovery Manager ORB Portability Transactional Object For Java
| print this page
| email this page
- Overview of the OMG Object Transaction Service 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)
Copyright 2002-2005 Arjuna Technologies All Rights Reserved. info@arjuna.com +44 191 243 0676