Experiences With Building a Federated Transaction Manager Based on CORBA OTS

1. Experiences With Building a Federated Transaction Manager Based on CORBA OTS Ralf Schenkel and Gerhard Weikum University of the Saarland

2. Overview of the Talk • Architecture of VHDBS • Motivation and State of the Art • Concepts of the Transaction Manager • Implementation Issues • Conclusion Engineering Federated Information Systems '99

3. Architecture of VHDBS Engineering Federated Information Systems '99

4. Motivation Federate applications ask for • atomicity of distributed changes • correct execution (global serializability) • consistency preservation • durability of committed changes in a highly heterogeneous environment Engineering Federated Information Systems '99

5. Global Serializability Local serialization orders are not compatible  execution is not globally serializable Engineering Federated Information Systems '99

6. Multilevel Transactions Use information about semantics of operations to guarantee global serializability Engineering Federated Information Systems '99

7. State of the Art Atomicity: • Atomic Commit Protocols (2PC through XA-interface) • Compensation or Retry of aborted subtransactions Serializability: • Exploit properties of local schedulers (commit-order) • Force local conflicts (ticket methods) • Multilevel transactions But: Not much impact in systems • Potential performance bottlenecks • unrealistic assumptions about local schedulers • No universally “best” strategy • Isolation levels are completely ignored Engineering Federated Information Systems '99

8. Overview of CORBA OTS Atomicity: • implementation of two-phase commit protocol with CORBA-style interfaces • easy integration of DBs with XA interface, possible to integrate other resources • nested transactions for finer rollback granularity Concurrency Control: • supports only very basic locking mechanism (OCCS) • closed nested transactions Two Programming Models: • implicit (transaction propagation automatically by OTS) • explicit (transaction context as parameter to method calls) Engineering Federated Information Systems '99

9. Why OTS is not enough Simple and straight-forward approach: 1. The client begins an OTS transaction. 2. The context of that transaction is passed implicitly with all method calls of the client. 3. The client commits the OTS transaction. This is not appropriate: • Granularity of implicit context propagation is not fine enough (all methods of an interface or none) • No OTS built-in support for advanced global strategies, so client programs have to make additional calls • Solution: • dedicated transaction server TRAFIC • clients start and commit transactions through this server • TRAFIC handles all OTS-specific issues Engineering Federated Information Systems '99

10. Architecture of TRAFIC 1 Engineering Federated Information Systems '99

11. Architecture of TRAFIC 2 • Modular architecture with IDL interfaces • Clear separation between strategies and mechanisms to allow a re-use of mechanisms • Strategies as instances of generic interface CCStrategy to allow an easy extension • ODMG-like interface for transaction control: • Transactions are represented by Transaction objects with methods to commit and abort • TransactionFactory to begin transactions • support for multiple threads in one transaction • Every “transactional” method call by VHDBS is re-routed through TRAFIC by Orbix-specific Smart Proxies • TRAFIC handles all OTS-specific issues Engineering Federated Information Systems '99

12. Implementation Issues 1 Implementation of Flat Transactions: • TRAFIC begins an OTS transaction upon BOT • all transactional calls are made in the context of this OTS transaction • TRAFIC commits/aborts the OTS transaction when commit/abort is requested by the client Problems: • Unclear how to use multiple threads within one OTS transaction • Impossible to use OTS-subtransactions together with explicit propagation • solution: OrbixOTS-specific extension for multi-threading Engineering Federated Information Systems '99

13. Implementation Issues 2 Implementation of Multilevel Transactions • TRAFIC uses a new OTS transaction for all method calls • Inside this transaction, • a semantic lock is acquired, • the method call is executed, • a compensation log record is written (if necessary) Problems: • OTS nested transactions are unusable (subtransactions don’t free their locks upon their commit) • CORBA locks (OCCS) are too restrictive • Database cursors can’t be used across transactions Engineering Federated Information Systems '99

14. Conclusion • CORBA as a convenient framework for the communication architecture • OTS provides a well-working implemen-tation of the 2-phase-commit protocol • OTS does not help to guarantee global serializability, so an additional federate concurrency control is necessary • First steps towards a support for isolation levels Engineering Federated Information Systems '99

15. Questions? What does this have to do with XML? Engineering Federated Information Systems '99

16. Requirements for a TA Manager • Extensible (easily add new strategies) • support a wide variety of systems • easy to use for clients (ideally: add only BOT and EOT markers) • support local isolation levels • offer isolation levels for federate TAs • implementation-independent • interoperable • scalable Engineering Federated Information Systems '99

17. Dealing with Isolation Levels Engineering Federated Information Systems '99