[email protected] +1 (973) 829 4644

(1)

CORBA Object Transaction Service

Telcordia Technologies Proprietary – Internal Use Only

This document contains proprietary information that shall be distributed, routed or made available only within Telcordia Technologies, except with written permission of Telcordia Technologies.

Telcordia Contact:

Paolo Missier

[email protected] +1 (973) 829 4644

March 29th, 1999

An SAIC Company

Transactional Support for Distributed Objects

Ÿ Goals of Distributed Transaction Processing in CORBA:

– Ensure data integrity across multiple heterogeneous sources – Compatibility with existing CORBA services

– No extensions to the CORBA core (IDL, ORB)

– Interoperability with existing TP Monitors (CICS, Tuxedo, etc.)

(2)

CORBA OTS – 3 Telcordia Technologies Proprietary - Internal use only. See proprietary restrictions on title page.

Basic ACID Transactional Model: quick review

Ÿ Atomicity

– Either all or none of the transaction’s operations are performed

– If a transaction is interrupted by a failure, its partial results must be undone Ÿ Consistency

– Consistent database state: integrity constraints are not violated – Upon conclusion, transactions leave the database in a consistent state – Consistency degrees are defined to specify the acceptable behavior of

concurrent transactions Ÿ Isolation

– Serializability: the effect of concurrent transaction execution must be the same as that of some serial order

– An incomplete transaction cannot reveal its partial results Ÿ Durability

The need for (Distributed) Transactions:

Ÿ Canonical example: transactional credit-debit application Ÿ Other uses of DT P: keeping replicas synchronized

– alternative: use replica managers

– may use Corba to handle cached data with write-through propagation to the

storage

(3)

Resource Managers

Ÿ RMs provide ACID operations on a set of data

Ÿ “any subsystem that implements transactional data can be a RM” [Gray]

Ÿ Examples: DBMS, transactional file systems, transactional queue managers

Transactional Applications

Ÿ T ransaction execution spans several app servers and Resource Managers

Transaction Manager Application

Application Servers

Resource Managers

Resource

Managers

(4)

The Transaction Manager

Ÿ Monitors the transaction progress Ÿ Connects clients to servers

Ÿ Coordinates commit and rollback operations Ÿ Manages failures (system recovery)

The X/Open DTP Model

Ÿ Portable Interfaces: XA and TX – TX defines the 2-Phase Commit Protocol

Application

Resource Managers Transaction

Manager

Requests Begin Commit

Abort

Join

Prepare Commit Abort TX

XA

(5)

The 2-Phase Commit Protocol

Ÿ Prepare: Invoke each RMs involved in the transaction, asking for a vote

Ÿ Decide:

– if all RMs v ote Yes:

Ÿwrite the commit record in the transaction log ŸCommit: send the commit decision to each RM

ŸComplete: When all the RMs acknowledge the commit message, write the end- of-transaction record in the log, and deallocate the transaction.

– if at least one RM votes No:

ŸAbort: send the abort decision to each RM

ŸComplete: When all the RMs acknowledge the abort message, write the end-of- transaction record in the log, and deallocate the transaction.

X/Open’s DTP Reference Model for DTP - summary

Ÿ XA and TX: Protocols for Distributed Transactions Ÿ Main entities involved in TP:

– The application (AP) – The Resource Manager (RM) – The Transaction Manager (TM) Ÿ Procedural interfaces:

– XA between TM and RM – TX between AP and TM Ÿ Limitations:

– Interfaces are defined at the programming language level (C, COBOL) – The model does not indicate how invocations are propagated across

process/address spaces

(6)

Transaction Processing Monitors

Ÿ Built as a Transactional layer on top of the Basic OS (TPOS) – TRPC

Ÿ Enforce transactional properties of client/server interactions Ÿ Provide load balancing, execution monitoring and control Ÿ Intrusive (performance overhead)

Known Limitations of TP Monitors

Ÿ Its presence is not transparent to applications and servers Ÿ Not amenable to distributed object-oriented computing Ÿ General lack of Java support

– Tuxedo provides a Java-based gateway (JOLT)

Ÿ Expensive, requires substantial management

(7)

CORBA OTS = DTP + Distributed object computing

Relation with the X/Open Ref. Model

Ÿ Two main improvements:

– The procedural XA and TX interfaces are replaced with a set of CORBA IDL interfaces

ŸResource [10.3.7], Current [10.3.1]

– All inter-component communication (i.e., TM, RMs, AP) occur via CORBA calls on instances of implementations for these interfaces Ÿ OTS is fully compatible with X/open-compliant software

– tTransactions can be imported from and exported to [10.4.11] XA- compliant RMs and TX-compliant TMs

Ÿ OTS defines [optional] support for Nested Transactions

(8)

OTS Functional Goals

Ÿ Co-existence with legacy transactional environments Ÿ Support for nested transactions (optional)

Ÿ Model Interoperability:

– interoperability with the X/Open DTP model – Object access to existing Resource Managers Ÿ Network interoperability:

– multiple TSs and/or multiple ORBs Ÿ Support for TP Monitors

– clients, serv ers, and TSs may run in separate processes – TS must be usable in a TP Monitor Environment

OTS Design Goals

Ÿ Low implementation cost:

– Minimal impact on the existing ORB – Reuse of existing Transaction Managers – Low maintenance, simpler than typical TPM Ÿ Portability

– Applications (across OTS implementations) – OTS implementations (across ORBs) Ÿ No impact on IDL for existing interfaces

– Implementation of the same IDL can be transactional or non-transactional

(9)

OTS Performance Goals

Ÿ Achieve performance benchmarks similar to X/Open DTP for:

– number of network messages – number of disk accesses – amount of data logged

Ÿ Note that X/Open is procedural, not OO.

Ÿ Actual benchmarking of Inprise’s ITS in progress in our group – ITS performance for Oracle-based transactions against native Oracle

distributed transaction facility

Approaches to OTS implementation: Inprise’s ITS

Ÿ Fully integrated with the ORB

Ÿ No need for a separate TS on each node Ÿ Scalable together with the underlying ORB Ÿ Entirely Java-based

Ÿ RMs can be Corba servers

(10)

Approaches to OTS implementation: IONA’s OTM

Ÿ The ORBs interfaces with a back-end TP Monitor

Ÿ TS provides interface to specific TPM => users locked into choice of T PM

Ÿ TS cannot be discovered dynamically => TPM required at each node Ÿ Calls to TPM are not IIOP

Ÿ High maintenance

Approaches to OTS implementation: BEA’s M3

Ÿ Existing TP Monitor (Tuxedo) + ORB Ÿ The TP Framework provides:

– Object state management (activation, deactivation) and lifecycle – T ransaction management: interface with M3 transaction manager – System events notification to clients

Ÿ Clear distinction among:

– Development: framework-based – Deployment

ŸOTS, Security, LifeCycle

ŸFault Management, Routing, Load Balancing – Operations: management tools

Ÿ Advantage: tight integration with TPM. Useful framework

Ÿ Disadvantage: tight integration with TPM. Rigid framework

(11)

OTS elements: Transaction Context

Ÿ Goal: to provide trasnaction synchronization across the elements of a distributed c/s application

Ÿ Originator: the client app that requests transaction initiation to the OTS Ÿ T ransaction Context (Scope):

– Created and managed by the OTS when originator requests transaction initiation;

– Shared by participants;

– Associated to the originator’s thread;

– Propagated to objects that participate in the transaction (transactional objects)

– Propagation can be implicit (done by the OTS), or explicit (as a parameter in CORBA calls)

OTS Elements: Transactional Objects

Ÿ An object whose behavior is affected by being invoked within the scope of a transaction

Ÿ Contains (a reference to) persistent data that is manipulated by the transaction

Ÿ Scope of the transaction context:

– a tr.obj. can decide which methods are within the context. Some methods may remain non-transactional

Ÿ The same interface can have both transactional and nontransactional implementations

Ÿ T ransactional objects are used to implement two kind of application servers:

– T ransactional Server

– Recov erable Server

(12)

Recoverable and Resource Objects

Ÿ Recoverable objects are Transactional objects that participate in the recovery protocol (after a failure)

Ÿ Resources are server objects that implement the Resource interface (X/Open TX interface):

– prepare() – rollback() – commit()

– commit_one_phase()

Basic scenario for OTS use

To ₁

Res ₁

Originator

OTS

To ₂

Res ₂ Begin()

Commit()

Register()

Op

₁

() Op

₂

()

SQL

₁

SQL

₂

Register()

Prepare() Commit()

¬ - a

® a

¯ a

°

± a

- b

® b

¯ b

± b

(13)

Interaction Diagram for Basic Scenario

originator OTS To1 Res1 To2 Res2

1: begin()

2: op1() 3: register_resource()

4: SQL1 5: return 6: return

7: op2() 8: register_resource()

9: SQL2 10: return 11: return

Interaction Diagram for Basic Scenario - 2PC

originator OTS To1 Res1 To2 Res2

12: commit()

13: prepare()

15: prepare() 14: yes

16: yes 17: commit()

18: commit()

19: ack

20: ack

(14)

Transaction Creation: Current interface

Ÿ Used to begin, end and query the status of a transaction Ÿ Current defines operations for the management of associations

between threads and transactions

– one transaction can be associated to more than one thread Ÿ Simple to use. Typical idiom:

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();

org.omg.CORBA.Object initRef =

orb.resolve_initial_references("TransactionCurrent");

current = CurrentHelper.narrow(initRef);

current.begin();

Transaction Creation: TransactionFactory

Ÿ Idiom:

Ÿ More restrictive than Current. The Control object may be restricted for use in other environments.

Ÿ Can be used to import transactions that originates outside of the TS

CosTransaction::Control c;

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();

TransactionFactory Tfactory =

TransactionFactoryHelper.bind(orb);

c = TFactory->create(timeout);

(15)

Context Management: the Control interface

Ÿ One Control object is associated with each transaction Ÿ Control is obtained by:

– Current::get_control() – Current::suspend()

– TransactionFactory::create()

Ÿ It contains a Coordinator and a T erminator

Ÿ Coordinator can be used by a transactional object to:

– register resources: Coordinator::register_resource(in Resource r);

– force a transaction to rollback: Coordinator::rollback_only();

Ÿ T erminator is used by the originator to:

– commit: Terminator::commit();

– rollback: Terminator::rollback();

Transaction Propagation

Ÿ A call on a transactional object may or may not be transactional.

Ÿ In the example scenario:

Op ₁ (), Op ₂ () are transactional calls

Ÿ How is the transaction context passed to T o ₁ , To ₂ ? Ÿ Explicit propagation:

– theControl object is passed as a parameter in the call, e.g.

void To1.Op1(in CosTransaction::Control c, …)

Ÿ Implicit propagation: transactional objects inherit from a marker interface in the IDL:

To : CosTransaction::TransactionalObject

(16)

Resource Registration

Ÿ Manual registration:

– Res1 implements the CosTransactions::Resource interface – To1 registers Res1 using the Coordinator

– Typically, resource registration is the first action in a transactional call – Note: in some implementations, the Coordinator object is not directly

available (i.e. in M3). In those cases, this method cannot be used.

Ÿ Automatic registration:

– Resource has native support from OTS, or it supports the XA/TX interface – Registration is static and occurs before any request to the resource.

– OTS can reach the resource’s XA interface

Notes on XA and native support

Ÿ Inprise provides integrated XA Resource Directors for some XA - compliant resources. How ever, it is restricted to specific DBMS (e.g.

Oracle) and specific versions

Ÿ Orbix only provides filters for registering XA resources Ÿ Native support depends on specific arrangements among ORB-

DBMS/TP Monitor vendors

– Orbix natively supports the Encina TP monitor by Transarc

– Inprise supports generic connection to a TP Monitor

– M3 is designed around the Tuxedo TP Monitor

(17)

Transaction Termination

Ÿ Only the originator should terminate the transaction.

Ÿ Indirect termination:

– Use

ŸCurrent::commit(in boolean report_heuristics) ŸCurrent::rollback()

– heuristics = True: call blocks until all resources are done

– heuristics = False: call returns after prepare phase (faster for client) Ÿ Direct termination:

– Use

ŸTerminator::commit(in boolean report_heuristics) ŸTerminator ::rollback()

OTS interfaces summary

(18)

Scenario II: Resources as Corba services

To ₁

Originator

OTS

To ₂ Begin()

Commit()

Register()

Op

₁

() Op

₂

()

Register()

Prepare() Commit() Prepare()

Commit()

¬ - a

® a

¯

- b

® b

Res ₁ Rm ₁ SQL

₁

¯ a

Res ₂ Rm ₂ SQL

₂

° a ° b

Multithreaded transaction execution

Ÿ In Scenario I and II, there is a potential for concurrent execution of parts (a) and (b)