CORBA Object Transaction Service - Roma Tre Universityatzeni/psfiles/OTS.pdf · CORBA Object...

1

CORBA Object Transaction Service

Telcordia Technologies Proprietary – Internal Use OnlyThis document contains proprietary information that shall be distributed, routed or made available onlywithin Telcordia Technologies, except with written permission of Telcordia Technologies.

Telcordia Contact:Paolo [email protected]+1 (973) 829 4644March 29th, 1999

An SAIC Company

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

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


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 DTP: 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

�Transaction execution spans several app servers and ResourceManagers

Tran

sact

ion

Man

ager

Application

ApplicationServers

ApplicationServers

ResourceManagers

ResourceManagers

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

ResourceManagers

TransactionManager

Requests

BeginCommitAbort

Join

PrepareCommitAbort

TX

XA

5


The 2-Phase Commit Protocol

�Prepare: Invoke each RMs involved in the transaction, asking for avote�Decide:

– if all RMs vote 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 viaCORBA 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, servers, 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 Oracledistributed 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

TPM�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– Transaction 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 adistributed c/s application�Originator: the client app that requests transaction initiation to the OTS�Transaction Context (Scope):

– Created and managed by the OTS when originator requests transactioninitiation;

– 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 thescope 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 methodsmay remain non-transactional

�The same interface can have both transactional and nontransactionalimplementations�Transactional objects are used to implement two kind of application

servers:– Transactional Server– Recoverable Server

12


Recoverable and Resource Objects

�Recoverable objects are Transactional objects that participate in therecovery 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

To1

Res1

Originator

OTS

To2

Res2

Begin()Commit()

Register()

Op1() Op2()

SQL1SQL2

Register()

Prepare()Commit()

Prepare()Commit()

¬

a

®a

¯a

°

±a

b

®b

¯b

±b

13


Interaction Diagram for Basic Scenariooriginator OTS To1 Res1 To2 Res2

1: begin()

2: op1()

3: register_resource()

4: SQL1

5: return6: return

7: op2()

8: register_resource()

9: SQL2

10: return11: return


Interaction Diagram for Basic Scenario - 2PCoriginator 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 foruse 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 Terminator�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();

�Terminator 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:

Op1(), Op2() are transactional calls

�How is the transaction context passed to To1, To2?

�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. However, 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

To1

Originator

OTS

To2Begin()

Commit()

Register()

Op1() Op2()

Register()

Prepare()Commit()

Prepare()Commit()

¬

a

®a¯

b

®b

Res1

Rm1

SQL1

¯aRes2

Rm2

SQL2

°a °b


Multithreaded transaction execution

�In Scenario I and II, there is a potential for concurrent execution ofparts (a) and (b)�However, transaction Control is associated with one thread in the

originator�Solution:

– in the originator, split the client into two threads– in each thread, the same Control object ctrl is visible– in each thread, the resume() method is called on ctrl

19


Multi-tier Application Deployment ScenarioClientApp

DBMS TPM

OTS

TX TX/XA

SQL

IIOPIIOP IIOP

IIOP

OrderManager Server

Data Wrapper Data Wrapper

presentation

B.O.middle tier

Wrappers

Data Layer


Multi-tier Scenario: ORB-centric view

ClientApp

Data Wrapper Data Wrapper

DBMS TPM

OrderManagerServer

OTS

ORB

20


Multi-tier deployement detailClientApp

InventoryManager

AccountManager

OrderManager

(originator)

Inventory DB Account DB

Inventory StorageManager

Oracle client

Account StorageManager

Oracle clientOTS

presentation

B.O.middle tier

Wrappers

Data Layer

TX TXSQL SQL

IIOPIIOP IIOP

IIOP

CORBA Object Transaction Service - Roma Tre Universityatzeni/psfiles/OTS.pdf · CORBA Object...

Documents

Transcript of CORBA Object Transaction Service - Roma Tre Universityatzeni/psfiles/OTS.pdf · CORBA Object...