Global nested transaction management for ODMG-compliant multi-database systems

Abstract

Object technology has received considerable attention in the re cent years for the integration of various local data sources in a multi-database system (MDBS). An object-oriented data model like ODMG-93 can serve as the canonical data model for the global layer in the MDBS. The ODMG-93 standard defines a closed nested ACID transaction model without intra-transaction parallelism. Although the nested transaction model provides special support for distributed computing enviromnents, the implications of its usage as a global transaction model for MDBS have so far not been examined.In this paper, we present a simple and practical method to implement global nested transaction management for ODMGcompliant multi-database systems. The main contribution of our work is the adaption of the ticket method to achieve global serializability for global nested transactions that conform to ODMG. Our approach is also applicable to OMG's common object request broker architecture. We have successfully implemented our global nested transaction model within the IRO-DB multi-database system.

HyperStorM

“…So far, our hypermedia engine can support multiple users working on the same hypermedia database. In the future, we want to extend our approach to include support for cooperative applications (R5) as well [26]. This requires, e.g., the development of new modeling constructs in the abstract hypermedia data model, the extension of current DBMS concepts and technology to support cooperative transaction models [21,29], and the integration of versioning [10].…”

Federating object-oriented and relational databases: the IRO-DB experience

“…The disadvantage is that the ODMG-standard would need to be extended to support this approach, and that specification of the necessary global conflict semantics is fairly complex. [30]. The ticket method achieves global serializability by the explicit introduction of direct conflicts between the local interoperable transactions through a dedicated ticket object stored as regular data object in each local database.…”