CORBA Object Transaction Service

Transcription

1 CORBA Object Transaction Service Telcordia Contact: Paolo Missier +1 (973) March 29th, 1999 An SAIC Company 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. 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.) CORBA OTS 2 1

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 CORBA OTS 3 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 CORBA OTS 4 2

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 CORBA OTS 5 Transactional Applications Transaction execution spans several app servers and Resource Managers Application Servers Application Servers Application Resource Managers Resource Managers Transaction Manager CORBA OTS 6 3

4 The Transaction Manager Monitors the transaction progress Connects clients to servers Coordinates commit and rollback operations Manages failures (system recovery) CORBA OTS 7 The X/Open DTP Model Portable Interfaces: XA and TX TX defines the 2-Phase Commit Protocol Application TX Begin Commit Abort Requests Join Transaction Manager Resource Managers Prepare Commit Abort XA CORBA OTS 8 4

5 The 2-Phase Commit Protocol Prepare: Invoke each RMs involved in the transaction, asking for a vote 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 endof-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-oftransaction record in the log, and deallocate the transaction. CORBA OTS 9 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 CORBA OTS 10 5

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) CORBA OTS 11 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 CORBA OTS 12 6

7 CORBA OTS = DTP + Distributed object computing CORBA OTS 13 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 [ ] XAcompliant RMs and TX-compliant TMs OTS defines [optional] support for Nested Transactions CORBA OTS 14 7

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 CORBA OTS 15 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 CORBA OTS 16 8

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 CORBA OTS 17 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 CORBA OTS 18 9

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 CORBA OTS 19 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 CORBA OTS 20 10

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 Transaction 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) CORBA OTS 21 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 Transactional objects are used to implement two kind of application servers: Transactional Server Recoverable Server CORBA OTS 22 11

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() CORBA OTS 23 Basic scenario for OTS use 2a Originator Op 1 () Op 2 () 2b To 1 Begin() 1 Commit() 5 SQL 1 4a Register() Register() 4b SQL 2 3a 3b Res 1 Res 2 6a 6b Prepare() OTS Prepare() Commit() Commit() To 2 CORBA OTS 24 12

13 Interaction Diagram for Basic Scenario originator OTS To1 Res1 To2 Res2 1: begin() 2: op1() 3: register_resource() 6: return 4: SQL1 5: return 7: op2() 8: register_resource() 9: SQL2 11: return 10: return CORBA OTS 25 Interaction Diagram for Basic Scenario - 2PC originator OTS To1 Res1 To2 Res2 12: commit() 13: prepare() 14: yes 15: prepare() 16: yes 17: commit() 18: commit() 19: ack 20: ack CORBA OTS 26 13

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(); CORBA OTS 27 Transaction Creation: TransactionFactory Idiom: CosTransaction::Control c; org.omg.corba.orb orb = org.omg.corba.orb.init(); TransactionFactory Tfactory = TransactionFactoryHelper.bind(orb); c = TFactory->create(timeout); 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 CORBA OTS 28 14

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(); CORBA OTS 29 Transaction Propagation A call on a transactional object may or may not be transactional. In the example scenario: Op 1 (), Op 2 () are transactional calls How is the transaction context passed to To 1, To 2? 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 CORBA OTS 30 15

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 CORBA OTS 31 Notes on XA and native support Inprise provides integrated XA Resource Directors for some XAcompliant 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 CORBA OTS 32 16

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() CORBA OTS 33 OTS interfaces summary CORBA OTS 34 17

18 Scenario II: Resources as Corba services 2a Originator Op 1 () Op 2 () 2b To 1 3a Begin() 1 Commit() 4 3b To 2 Rm 1 Rm 2 SQL 1 Res 1 5a 4a Prepare() Commit() Register() OTS Register() 5b Prepare() Commit() SQL 2 Res 2 CORBA OTS 35 Multithreaded transaction execution In Scenario I and II, there is a potential for concurrent execution of parts (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 CORBA OTS 36 18

19 Multi-tier Application Deployment Scenario OrderManager Server Client App IIOP presentation B.O. middle tier IIOP Data Wrapper IIOP IIOP Data Wrapper SQL O T S Wrappers DBMS TX TX/XA TPM Data Layer CORBA OTS 37 Multi-tier Scenario: ORB-centric view Client App OTS ORB Data Wrapper OrderManager Server Data Wrapper DBMS TPM CORBA OTS 38 19

20 Multi-tier deployement detail Client App presentation IIOP Account Manager Order Manager (originator) Inventory Manager B.O. middle tier IIOP IIOP IIOP Inventory Storage Manager Oracle client SQL TX O T S TX Account Storage Manager Oracle client SQL Wrappers Inventory DB Account DB Data Layer CORBA OTS 39 20