06 ORBs

Category: Education

Presentation Description

No description available.


Presentation Transcript

Transaction Processing Concepts and Techniques : 

Transaction Processing Concepts and Techniques Transaction Processing and Objects A sensational event was changing from the brown suit to the gray the contents of his pockets. He was earnest about these objects. They were of eternal importance, like baseball or the Republican Party. Sinclair Lewis: Babbitt 9:00 11:00 1:30 3:30 7:00 Overview Faults Tolerance T Models Party TP mons ORBs Locks Locks Workflow Log ResMgr TranMgr Adv TM Cyberbrick Buffers COM+DTC files+ Records Party B-tree Benchmarks Corba Tuxedo Systems Mon Tue Wed Thur Fri

Problem Background: 

Problem Background For technical and organizational reasons, distributed systems are the platform for all future (business) computing. While the importance of data sharing increases,the need for local autonomy and diverse functionality increases as well. Systems grow in size and complexity, and at the same time undergo permanent change, both structurally and functionally.

Problem Background: 

Problem Background The dominant paradigm for structuring such systems is the client/server approach. The interoperability of heterogeneous clients and servers that are routinely relocated is performed by an ever-increasing piece of software called “middleware”.


What is Middleware? Client Server Middleware GUI OOUI System Mgmt. OS Objects Group- ware TP-Mon. DBMS OS SQL ORB TRPC Security Transport Mail WWW Files etc. You have seen that picture before.


More Specifically, Middleware ... contains protocol converters for heterogemeous networks; mediates access to heterogeneous (federated) databases; provides the infrastructure for session-based and RPC-style communication; is called “TP monitor” in some (or actually: many) systems;


More Specifically, Middleware ... provides the system management tools for administering large, dynamically evolving systems; supports the integration of different functional domains (e.g. structured databases with text or with audio/video streams); allows components (objects) to work together in a coherent fashion.


The Role of Objects Encapsulation is a fundamental requirement for software components in dynamically changing distributed systems. Object oriented design and implementation encourage component software, which is designed and implemented without any information about the future execution environment.. The object-oriented way of structuring systems is based on the concepts as the operational metaphor of distributed client/server systems. Therefore, they should complement each other nicely.


Avoiding Object Babylon: The OMG The OMG is an international consortium that tries to come up with an object Esperanto. It is a bag full of new acronyms: ORB, OMA, CORBA, IDL, BOA, GIOP, IIOP, ESIOP, POS, OTS, etc. There is a T in there, which means “transactions”. While CORBA defines some kind of an RPC mechanism (OO style), the object transaction service (OTS) specifies how to merge objects and transactions. There are other approaches to solve the same problem, most notably Microsoft´s OLE/TP for their component object model (COM).


OTS: The BIG Picture Object Request Broker (ORB) Object Transaction Service TA context TA client 1 2 3 3 4 5 6 7 TA object rec. object resource Sub-TA res. TA server Recoverable server Distributed Client-Server Application


OTS Interfaces 1 A transactional client requests begin or end of transaction. If upon a begin request, a TA already exists, a sub-TA is started. 2 The client invokes operations from a transactional object. Such an object has no persistent state. 3 Requests can also be made at recoverable objects. 4 Registers a resource object with the OTS for commit coordi-nation; may initiate rollback.


OTS Interfaces 5 A resource understanding sub-TAs implements what is needed for completing a sub-TA, passing the locks to the parent, etc. 6 A resource participates in the 2PC, makes changes to persistent state durable, performs recovery if needed, etc. 7 A transactional object may initiate rollback.


Transaction Context OTS maintains a transaction context for each active TA. It is associated with all transactional operations. The TA context is an implicit parameter for all invocations of TA operations. The context can also be passed as an explicit parameter. This is required in environments where both the OTS style and the procedural (X/Open DTP) style of transactions are used in parallel.


The Transaction´s New Clothes Boolean Debit (Amount amountRequested) { Account theAccount; Branch theBranch; Teller theTeller; History GlobalHistory; Current theCurrentTransaction; theCurrentTransaction.begin(); Amount balance = theAccount.query(); if (balance >= amountRequested) { theAccount.withdraw(amountRequested); theBranch.withdraw(amountRequested); theTeller.withdraw(amountRequested); GlobalHistory.remember(amountRequested); theTeller.dispense(amountRequested); theCurrentTransaction.commit(); return True; else ...


OTS Interfaces Current denotes a pseudo object, the methods of which are executed within OTS and ORB. Invoking begin on an object of class current creates a transaction context that is managed by the ORB until the TA either commits or aborts. As a result of begin, the newly created context is associated with the client´s “thread of control”, which typically translates into “process”. Multiple threads (in different execution environments) can be associated with the same context at the same time.


OTS Interfaces: Methods of Current interface Current { void begin() raises(SubtransactionsUnavailable); void commit (in boolean report_heuristics) raises(NoTransaction, ....); void rollback() raises(NoTransaction); void rollback_only() raises(NoTransaction); Status get_status(); string get_transaction_name(); void set_timeout(in unsigned long seconds); Control get_control(); Control suspend(); void resume(in Control which) raises(InvalidControl);


The Machinery Behind Current The Current pseudo object is intended to facilitate the life of a transactional client. In fact, it combines the functionality of a number of real objects: Factory: Creates a new transcation (optionally with timeout). Control: Allows to explicitly manage or propagate transactional context. Terminator: Supports the operations required to get rid of a transaction - for good or worse. Coordinator: Supports the participants of a transaction. Those recoverable objects or subordinate coordinators.


The Resource Interface interface Resource { vote prepare(); void rollback() raises(....); void commit() raises(....); void commit_one_phase() raises(....); void forget(); That should look vaguely familiar, after all.


Some Observations Many optimizations of classical transaction systems are missing; they seem to be considered “legacy” by OTS. There is no presumed abort, no transaction chaining, no transfer of commit, no checkpoint - remember the coordinator is a separate object. On the “Pro” side, OTS encourages nested transactions, provides explicit context management and object-controlled recovery. Using transaction context, one can precisely control what a certain object is allowed to do for a given transaction. Coexistence of OOTP and “old-style” TP is a prerequi-site for migrating legacy systems.


ORB vs. TP-Monitors Client Object communication Request Flow ORB Core The Greater ORB Dynamic ivocation IDL Stub ORB interface IDL skel. object adapter


Object Adaptors ... “provide flexibility in how an object is activated”. create new processes, if needed. create a new thread within an existing process. reassign an existing process and/or thread for a new invocation. multiplex a small number of object servers over a large number of object clients.


The Other ORB-Components ... do request routing, which is similar to RPC handling. perform type conversion and parameter marshalling. activate the objects that receive method calls; this may involve program loading and maintenance of the execution environment.


All Things Considered The functionality of the ORB plus the services provided by OTS are almost identical with the TPOS described in this class. The differences are in the terminology and in the programming model that sits on top of the “operating system”. From a technical perspective, a consolidation of OLTP-style applications and OO-style applications can be done on the same platform.


A Basic Dictionary IDL stub/ IDL skeleton:Client stub/ server stub. Object invocation: RPC Object identifier: RMID + primary key Object adaptor: TP monitor (process/thread mgmt., scheduling) Current, coordinator, terminator: Transaction manager Transactional server: Application Recoverable server: Resource Manager Transaction context: The T of TRPC


Acknowledgement This presentation draws on a draft paper on CORBA, OTS, and TP-monitors, which is written by Ed Cobb (IBM). The paper has been submitted for publication in the VLDB Journal and will probably appear in late 1996 / early 1997.

authorStream Live Help