Arbeitspapiere der GMD GMD Technical Report No. 1071

Transcription

1 Arbeitspapiere der GMD GMD Technical Report No Thomas Tesch, Jürgen Wäsch Global Nested Transaction Management for ODMG-Compliant Multi-Database Systems May 1997 GMD GERMAN NATIONAL RESEARCH CENTER FOR INFORMATION TECHNOLOGY

2 The Arbeitspapiere der GMD GMD Technical Reports primarily comprise preliminary publications, specific partial results and complementary material. In the interest of a subsequent final publication the Arbeitspapiere/Technical Reports should not be copied. Critical comments would be appreciated by the authors. No part of this publication may be reproduced or further processed in any form or by any means without the prior permission of GMD. All rights reserved. Copyright 1997 Addresses of the authors: Thomas Tesch, Jürgen Wäsch GMD-IPSI Dolivostraße 15 D Darmstadt Phone: +49/6151/869-{948, 959} Fax: +49/6151/ {tesch, waesch}@darmstadt.gmd.de WWW: waesch} Address all correspondence to: Karl Aberer GMD-IPSI Dolivostraße 15 D Darmstadt Phone: +49/6151/ Fax: +49/6151/ aberer@darmstadt.gmd.de WWW: 2

3 Abstract Object technology has received considerable attention in the recent years for the integration of various local data sources in a multi-database system (MDBS). An objectoriented 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 environments, 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 ODMG-compliant 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 succesfully implemented our global nested transaction model within the IRO-DB multi-database system. Keywords: Multi-Database Systems, ODMG, Nested Transactions, Global Serializability, Ticket Method, IRO-DB, OMG This work is initiated by the European ESPRIT project IRO-DB (P8629). The IRO-DB project is developed in cooperation with GMD, GOPAS, IBERMATICA, EDS, GRAPHAEL, INTRASOFT, FAW, and O2 Technology. PRiSM acts as a subcontractor of both GRAPHAEL and EDS. 3

4 4

5 1 Introduction A multi-database system (MDBS) enables applications to access data stored in a collection of database systems. In a MDBS the access to the constituent databases is controlled by autonomous component database systems, referred to as local database systems (LDBS). The MDBS concept assumes autonomy of LDBS, i.e., each participating component database system is under separate and independent control [SL90, Vei90]. The usage of a MDBS allows that pre-existing local application programs remain operational. At the same time, new global applications are able to access data in various distributed LDBS because a MDBS allows global transactions and local autonomous transactions to co-exist. Local autonomous transactions are executed outside the control of the MDBS whereas global transactions are controlled by the MDBS. Various approaches for the management of flat transactions in MDBS have been described in the recent years [BGMS92, ZE93, BS88, GRS91, MRKS92, GRS94]. Enforcing global serializability in MDBS is difficult because there may be indirect conflicts between global transactions caused by local autonomous transactions at a particular site which the MDBS is not aware of. A LDBS cannot be forced to externalize any information that can be used by the MDBS to determine the relative serialization order of global transactions because of LDBS autonomy.. In [GRS91, GRS94] the ticket method has been proposed to enforce global serializability of flat global transactions in MDBS. This is achieved by the explicit introduction of direct conflicts between global subtransactions through dedicated ticket objects stored as regular data objects in the local databases. The ticket method does not violate the autonomy of the LDBS, i.e., no LDBS software need to be changed and no local autonomous transaction submitted directly to a LDBS has to be modified. Object technology has received considerable attention in the recent years for the integration of the various local data sources within a MDBS. An object-oriented data model like ODMG-93 [Cat94, Cat96] can serve as the canonical data model for the global layer. An example is the IRO-DB system [GFF97, GGF + 96, RFFS95, BFHK94] which provides a standard ODMG interface for each participating local system to alleviate data model differences. The ODMG-93 standard defines a closed nested ACID transaction model [Mos82] without intra-transaction parallelism and with an additional checkpoint operation 1. Although the nested transaction model provides special support for distributed computing environments in terms of finer recovery granularity and extended control structures, the implications of its usage as a global transaction model for MDBS have so far not been examined. An exception is the work presented in [HAD97]. In this paper, we present a simple and practical method to implement global nested transaction management for ODMG-compliant MDBS, i.e., a MDBS where the LDBS supports (directly or by using an additional software layer) the ODMG-93 transaction model. Our approach is also applicable to OMG's common object request broker architecture. OMG's transaction specification defines a nested transaction model close to ODMG's approach [OMG94]. 1 It should be noted that in the release 1.2 of the ODMG-93 standard [Cat96], the nesting of transactions has been delayed to future revisions of ODMG-93. We always refer to release 1.1 of ODMG-93 [Cat94] in this paper. 5

6 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. One major point herein is the correct mapping of global nested transactions to multiple local nested transactions (cf. Section 4). In opposite to [HAD97], in our approach a single ticket object per local database is enough despite the nesting of global transactions. The reason for this simplification is that ODMG does not support intra-transaction parallelism. We have successfully implemented our global nested transaction model [TWL95] within the IRO-DB system [GGF + 96] (cf. Section 5). The implementation of the global transaction manager within IRO-DB required only minimal modifications to other pre-existing components of the MDBS layer in the IRO-DB system. 2 A Brief Review of the ODMG Transaction Model As in every DBMS, in ODMG [Cat94] all application programs that use persistent data have to be organized into transactions. Transactions in ODMG are atomic, consistent, isolated, and durable. The ODMG Object Model supports a nested transaction model with dynamic scoping, assumes a linear sequence of transactions within a single process, running against a single database [Cat94]. Nested transactions in ODMG refer to the closed nested transaction model [Mos82] without intra-transaction parallelism. The advantages of closed nested transactions in this respect are not utilized. ODMG's closed nested transactions provide only a finer recovery granularity. ODMG does not enforce any specific concurrency control and recovery policy nor does it specify a two-phase commit protocol for ODMG-compliant systems [Cat94]. As a default, locking-based pessimistic concurrency control is assumed where locks can be acquired on particular objects. Transactions are implemented in ODMG's C++ binding as transient objects of class Transaction. Objects of class Transaction support the following transaction control commands: 1 class Transaction{ 2 public: Transaction(); 3 Transaction(); 4 void begin(); 5 void commit(); 6 void abort(); 7 void abort_top_level(); 8 void checkpoint(); 9 } The operations begin(), commit(), abort() have the usual semantics. Nested transactions are created by nested begin() operations on different transaction objects (cf. Figure 2). The abort top level() operation aborts the top-level transaction including its already committed subtransactions, if there are any. The checkpoint() operation makes all objects accessed by the transaction persistent without committing the transaction. All references and pointers remain unchanged. An abort of the top-level transaction after a checkpoint rolls back the transaction only to the checkpoint and not to the database state at the beginning of the transaction. While ODMG-93 does not require (nor preclude) support for transactions [...] that 6

7 span more than one logical database [Cat94], our emphasis is to provide a simple and practical transaction management mechanism that supports global nested transactions that span more than one database system. 3 The Optimistic Ticket Method In a MDBS local autonomous transactions and global transactions are allowed to coexist. Local autonomous transactions are submitted directly to a single LDBS and run outside the scope of the MDBS while global transactions are submitted to the MDBS. A global transaction is decomposed by the global transaction manager (GTM) into multiple global subtransactions containing the data operations in the different local databases. The optimistic ticket method (OTM) [GRS91, GRS94] enforces global serializability by the explicit introduction of direct conflicts between global subtransactions in each involved local database. This is done by introducing a dedicated ticket object that is stored as a regular data object in each local database. The ticket value has to be read, incremented and written back to the database by each global subtransaction. In an object-oriented DBS this can be encapsulated in a take a ticket() operation that is invoked within each global subtransaction once in its lifetime. Because the ticket object is subject to local concurrency control, the ticket serves as a logical timestamp. Ticket objects do not need to be taken by local autonomous transactions that run outside the control of the MDBS. Thus, local transaction do not have to be modified. Within this respect the autonomy of the LDBS is not violated only the local database schema has to be enriched with a single ticket object. Since all global subtransactions at a particular site will directly conflict on the ticket object, the ticket values reflect their local serialization orders. Whether a certain execution of a global transaction is globally serializable or not is checked when the global transaction commits. A global transaction is only allowed to commit if its ticket values reflect the same relative serialization order in each involved LDBS. This is validated by the GTM by maintaining a global serialization graph (GSG). If the GTM detects a non-serializable schedule, i.e., a cycle in the GSG, it aborts the global transaction; otherwise the global transaction is committed by the GTM. For failure atomicity of global transactions, the GTM has to ensure that all of its global subtransactions are committed or none of them. The usage of a two-phase commit protocol [Gra78] requires that all LDBS support a visible prepared-to-commit state. Due to the autonomy of LDBS, global transactions can be involved in deadlocks that are not detectable by the MDBS. A solution to deal with this situation is to use timeouts. This policy is attractive for MDBS because of its simplicity and the independence from the local systems. To ensure global serializability, the OTM requires that (1) the concurrency control mechanism of the LDBS ensures serializability, (2) each global transaction has at most one global subtransaction per local database accessed, and (3) each global subtransactions has a visible prepared-to-commit state [GRS94]. Condition 1 is obviously fulfilled for ODMG-compliant DBS. Condition 2 has to be ensured by the GTM when mapping the global nested transactions onto local transactions (cf. Section 4). Condition 3 is not necessarily fulfilled for ODMG- 7

8 Figure 1: Different transaction types and their relationship. compliant DBS but we can simulate the prepared-to-commit state. Transactions are in a simulated prepared-to-commit state if they do not request further data operations and can not be aborted unilaterally by the LDBS [Geo91]. Due to the execution model and the dynamic scoping of transactions in ODMG, the GTM can be sure at global transaction commit that no further data operations on a local database are requested by the transaction (see also Section 5.2). 4 Decomposition of Global Nested Transactions In this section we discuss the decomposition of global nested transactions submitted to the ODMG-compliant MDBS and the correct mapping onto several local nested transactions executed at the local systems. To be precise in the description of the mapping we introduce the following terminology deviating from the usual terminology 2. A transaction submitted to the MDBS is called global interoperable transaction. If this transaction is nested it forms a tree consisting of several global interoperable subtransactions where the root is called global interoperable top-level transactions. We denote the local transactions executed on behalf of a global interoperable transaction as local interoperable transaction to distinguish them from local autonomous transactions submitted directly to a LDBS. If the meaning is clear we omit the term interoperable in the remainder of the paper. Figure 1 shows the different kinds of transactions and their relationships. A global top-level transaction is mapped by the GTM to n local top-level transactions executed at the participating LDBS. Note that local transactions are only created on demand, i.e., when the LDBS is accessed first. A local transaction itself may be nested. Global subtransaction may relate to many local subtransactions. The mapping has to consider the following conditions: (1) For each global transaction at most one local transaction per LDBS is created. (2) For each global subtransaction there has to be a corresponding local subtransaction at the same nesting level if the LDBS is accessed by the global subtransaction. The former condition en- 2 Please note that usually a local interoperable transaction is called global subtransaction in the multidatabase literature addressing only flat transaction management. 8

9 1 Transaction G1 = Transaction(); Transaction G122 = Transaction(); 4 5 G1.begin(); 6 G11.begin(); 7 <GlobalOperation1> // mapped to local operations A, B, C 8 // accessing LDBS L1 and L2 9 G11.commit(); 10 <GlobalOperation2> // mapped to local operations D, E 11 // accessing LDBS L1 and L2 12 G12.begin(); 13 G121.begin(); 14 <GlobalOperation3> // mapped to local operation F 15 // accessing LDBS L2 16 G121.commit(); 17 G122.begin(); 18 <GlobalOperation4> // mapped to local operations G, H 19 // accessing LDBS L1 and L2 20 G122.commit(); 21 G12.commit(); 22 G1.commit(); Figure 2: Sample global transaction program. sures requirement 2 of the optimistic ticket method which is needed to achieve global serializability (cf. Section 3). The latter condition ensures that the global and local transactions have the same recovery granularity, i.e., each global subtransaction can be individually aborted or committed by aborting or committing the appropriate local subtransactions. To illustrate the mapping, Figure 2 shows a sample transaction (pseudo-)program that can be executed by an ODMG-compliant MDBS. The global operations might be methods or queries defined on an interoperable database schema that are mapped by the MDBS software to local operations (again methods or queries) accessing the participating LDBS. If there is no interoperable schema available, the data operations accessing the local systems might be directly included in the transaction program. Figure 3 (a) shows the resulting (extended) global transaction tree. The inner nodes reflect the global (sub)transactions whereas the leaf nodes are local operations. The structure of this global transaction tree is determined by the order of invocations of transactional commands and global/local operations within the application program running at the MDBS layer. Figure 3 (b) shows the resulting local transaction trees for the LDBS L1 and L2 accessed by the global transaction. For each global (sub)transaction a corresponding local (sub)transaction exists in the local transaction trees if the global (sub)transaction accesses the particular LDBS. The correspondence between global and local (sub)transactions is indicated in the figure by the numbering of transactions. If a global (sub)transaction accesses a LDBS, the corresponding local (sub)transaction has to be on the correct nesting level, i.e., an appropriate number of ancestor transactions have to be started in the local transaction tree. If a global (sub)transaction or its descendants does not access the LDBS, there is no corresponding local (sub)transaction in the local transaction trees. Note, at most one local top-level transaction is created per LDBS accessed. Formally, we can treat a global nested transaction as a tree G = (N; A; <) with nodes N = N O [ N T. N T are (sub)transactions, N O are the data operations accessing 9

10 1 LDBS L1 1 LDBS L A B C D E F G H L1 L2 L1 L1 L2 L2 L1 L2 A C D G B E F H (a) Global Transaction Tree (b) Local Transaction Trees Transactions Local Operations Figure 3: Sample global nested transaction tree and its mapping to local nested transactions. the local systems. A denotes the ancestor relationship with (n; m) 2 A, n 2 ancestor(m), and < is a partial order defined over N denoting the execution order. The partial order on nodes t 2 N T is induced by the total ordering of data operations o 2 N O and the ancestor relationship: 8t; u 2 N T : (t < u, 9o; p 2 N O : o < p ^ (t; o) 2 A ^ (u; p) 2 A). To define the mapping of a global interoperable transaction tree G into local interoperable transactions, we introduce a function access : N O! LDBS where LDBS represents the set of local database systems. For each local system l 2 LDBS accessed by a global transaction G, i.e., 9n 2 N O : access(n) = l, we have a single local transaction L l. A local transaction tree is defined in the same way as a global transaction tree, i.e., L l = (N 0 ; A 0 ; < 0 ) with N 0 = N 0 [ N 0. The local transaction O T L l for a local database system l 2 LDBS is constructed bottom-up out of G in the following way: 1. N 0 O = fo j o 2 N O ^ access(o) = lg 2. N 0 = ft j t 2 N T T ^ 9o 2 N 0 : (t; o) 2 Ag O 3. A 0 = A j N 0 4. < 0 = < j N 0 Condition 1 says that all (and only those) data operations of G that access LDBS l are included in L l. Condition 2 ensures that all (and only those) transaction t have to be present in L l which have a data operation o accessing l as a child or which have a descendant that has a data operation o accessing l as a child. Conditions 3 and 4 state that the relations A 0 and < 0 are restrictions of A and < on the nodes N 0 of the local transaction tree L l. The last two conditions ensure that the local nested transaction has the same structure as the global nested transaction, i.e., the local transaction L l is a subtree of G. Finally, we present the basic functions of the GTM necessary to implement the mapping of global transactions onto local transactions. The functions are outlined in Figure 4. Details like 2-phase-commit, ticketing, and the global serialization test are discussed in Section

11 1 beginglobaltransaction() { 2 globalnestinglevel++; 3 } 4 5 registeraccess(ldbs l) { 6 insert l into accessedldbs; 7 while (globalnestinglevel > localnestinglevel[l]) 8 {beginlocaltransaction(l); 9 localnestinglevel[l]++; 10 } 11 } commitcurrentglobaltransaction() { 14 forall l in accessedldbs 15 {if (localnestinglevel == globalnestinglevel) 16 {commitcurrentlocaltransaction(l); 17 localnestinglevel[l]--;} 18 } 19 globalnestinglevel--; 20 } abortcurrentglobaltransaction() { 23 forall l in accessedldbs 24 {if (localnestinglevel = globalnestinglevel) 25 {abortcurrentlocaltransaction(l); 26 localnestinglevel[l]--;} 27 } 28 globalnestinglevel--; 29 } Figure 4: Outline of the GTM functions for the mapping of global nested transactions onto local nested transactions. The GTM maintains for mapping purposes two basic data structures for each global transaction: (1) the current nesting levels of the global and local transactions and (2) a set of all LDBS accessed by the global transaction. If a global top-level transaction or global subtransaction is started, i.e., beginglobaltransaction is called, the GTM increments the nesting level by 1. Note that this function does not start any local transactions. Local transactions are only started on demand, i.e., when the GTM is informed that a specific LDBS is to be accessed (registeraccess). In this case the GTM creates local (sub)transactions until the nesting levels of the local transaction and the global transaction are the same. If a global transaction is commited, the global nesting level is decremented by 1, all local transactions at the current nesting level are commited and their nesting level is decremented by 1. The processing of an abort of a global transaction is similar to the commit processing. 5 Realization in the IRO-DB system 5.1 The IRO-DB system In this section we briefly discuss the architecture of the IRO-DB system (Interoperable Relational and Object DataBases) for which we have implemented the global nested transaction management. The IRO-DB project aims at providing a set of tools to support the interoperability of existing relational DBS and new emerging object-oriented DBS. For this, IRO-DB has chosen to use ODMG-93 as the canonical data model. We 11

12 Application Program query result OQL query OQL Query Parser OET Global Query Translator modified/ optimized OET Global Query Evaluator sub results local site OET Query Delegator local local site sub result OQL query Schema Information IDD Schema Information method calls Object Management method calls results Home DBMS local results Interoperable Layer Communication Layer OQL/CLI Interface Local Layer Figure 5: Integration of the global transaction manager into the architecture of the IRO-DB system. focus in our description on components of the IRO-DB prototype that are important to know for the design of the global transaction manager. For further details on IRO-DB we refer the reader to [GFF97, GGF + 96, RFFS95, BFHK94]. The system architecture of the IRO-DB system (see Figure 5) can be divided into three layers: The local layer consists of several local database adapters (LDA) which are associated with a single LDBS. A LDA provides standard interfaces for accessing the participating LDBS and for exporting the external database schemata of the LDBS in terms of ODMG-93 schemata. The communication layer ensures reliable communication between the local database adapters and the interoperable layer. The interoperable layer provides integrated views of the local databases and their exported database schemata. These views are integrated within an ODMGcompliant Home-DBS. The interoperable layer implements the global transaction management module. Global applications programs interact with the interoperable layer using ODL and OQL with C++ binding interface. A global query is parsed by the query parser and dynamically decomposed at run-time into subqueries against the local systems. The decomposition of queries is done by the query translator and evaluator. The subqueries are submitted to the LDBS through the communication layer. The communication 12

13 Application Program with transaction tree consisting of IRO_Transaction objects... Application Program with transaction tree consisting of IRO_Transaction objects IRO_GTM IRO_GTM transaction path Global serialization graph Local transactions Shared GSG transaction path Global serialization graph Local transactions Local TA Local TA Local TA Local TA ticket value connection ticket value connection ticket value connection ticket value connection Communication Layer LDA 1 LDA 2 LDA 3 object reference Figure 6: The IRO-DB global transaction manager. layer receives the results of the subqueries and passes them back to the query evaluator that is responsible for the composition of the global query result. Methods of the interoperable schema are processed in a similar way by the object manager that is responsible for the decomposition of global methods defined in the interoperable schema, the delegation of local methods to the appropriate local system, and the composition of the result. Local subqueries and local method invocations have to be covered by transactions. Therefore, in addition to the transactional commands directly delegated to the GTM, the GTM is informed by the query evaluator and the object manager which local systems are accessed by a global query or method in order to request transactional support from the LDBS. The described execution model implies that the interoperable layer and the LDBS interact at a per operation basis. In opposite to so called service request architecture [BGMS92] this allows to submit ad-hoc queries and transactions because the local systems accept individual operations, i.e., queries and methods defined in their exported schema. 5.2 The global transaction manager In the following, we describe the internal structure of the GTM [TWL95]. Each application program is executed within an own process. Application programs use the C++ binding which defines a C++ class to support transaction semantics (see section 2). This class is called IRO Transaction and is part of the C++ API of the interoperable layer. Exactly one GTM instance (IRO GTM) is associated with the program as illustrated in Figure 6. Each operation on the IRO Transaction class and its instances are communicated to the GTM. The GTM instance maintains the current path 13

14 1 interface Ticket: persistent { 2 readonly attribute long ticketvalue; 3 long take_a_ticket(); /* increments ticketvalue */ 4 }; Figure 7: Ticket class in ODL. in the global nested transaction tree (including the current nesting level), references to ongoing local transactions, and their local nesting levels. With each local transaction, the GTM associates a connection handle and the ticket value after the ticket was taken. All GTM instances share the global serialization graph structure which is implemented in the Home-DBS. During the execution of global transactions, the GTM has to perform the mapping to local transactions dynamically. Before the local methods or queries can be submitted to the corresponding LDBS their execution has to be registered in the GTM. This is necessary in order to ensure that (1) a local transaction is available at the corresponding LDBS, and (2) the local transaction has the same nesting level as the global transaction. The GTM invokes the basic ODMG transaction management services of the LDBS via the local database adapters. The basic algorithm for this is presented in Figure 4. Note that for the processing of commit and aborts on global subtransactions no two-phase commit is required. Each local database contains a single ticket object. The ODL class definition of the ticket object is shown in Figure 7. The ticket objects are created by the local database adapters when the LDBS joins the federation. The operation take a ticket delivers the current ticket value and increments the value by one. The take a ticket operation is invoked by the LDA on behalf of the GTM. Maintaining a single ticket object for each local database is sufficient because local subtransactions of different local top-level transactions are serialized in the same order as their local top-level transactions. Global commit processing is initiated when the application program invokes the commit operation on the global top-level transaction. This is done by the GTM in the following steps: take the tickets, prepare the local transactions to commit, validate the global serialization order, and enforce the decision. Take tickets. Tickets are taken by the GTM from each involved local database the global transaction has accessed. This has to be done before the local transactions are prepared to commit because taking a ticket is an ordinary data operation. The ticket values are stored in the local transaction objects maintained by the GTM. By default we take tickets first when the global transaction is to be committed. Prepare the local transactions to commit. After the tickets are taken, the GTM acts as commit coordinator in a two-phase commit protocol. If a LDBS does not provide an explicit prepared-to-commit state, the prepared-to-commit state is simulated. A local transaction in a simulated-prepared-to-commit state is not unilaterally aborted for concurrency control reasons by a database system if it does not issue further data operations 3. Due to the fact that the execution model acts on a per-operation basis and 3 The only exception is the usage of Wound-Wait as deadlock resolution strategy which is very rare in commercial database systems [GRS94]. 14

15 transactions are dynamically scoped in ODMG, the GTM can be sure that no more local data operations are performed during global commit processing. Validate the global serialization order. After all local transactions are prepared-tocommit, the GTM checks the global serialization order, i.e., the validate operation is performed on the global serialization graph (GSG). The GSG is implemented as a shared data structure in the Home-DBS and maintains serialization dependencies between recently committed global top-level transactions, i.e., the nodes of the GSG. For any pair of transactions T 1 and T 2 in the GSG there exists a direct edge T 1! T 2 if at least one local transaction of T 1 was serialized before a local transaction of T 2 in the same local system (T 1 got a smaller ticket than T 2 ). The global transaction to be commited is validated against all global transactions in the GSG (backward validation). The serialization test adds for this transaction a new node T c. If a ticket obtained by a local transaction of T at some local database is smaller (larger) than the ticket of T c at the same local database, an edge T! T c (T c! T ) is added. The validation of T c succeeds if all edges are inserted and the graph contains no cycles. If it fails, T c and all inserted edges are removed from the GSG. Moreover, during the validation all nodes T are removed from the GSG if they have no incoming edges and all transaction that were active at the time T was committed are either committed or aborted [GRS94]. The validate operation is implemented as an atomic transaction in the Home-DBS to isolate it from concurrent validations of other global transactions. Enforce the decision. If the validation of T c was successful the GTM commits all local top-level transactions. If the validation failed all local transactions are aborted by the GTM. After that the GTM cleans up its internal data structures. If the application program aborts the global-top-level transaction (either by an abort() on the top-level transaction object or an abort top level() operation), the GTM simply aborts all local top-level transactions started on behalf of the global transaction. This is done by sending abort top level() to these local transactions. After that, the GTM cleans up its internal data structures. Similar to above, for the processing of an checkpoint() operation we rely on the ODMG-compliance of the LDBS. The GTM simply issues checkpoint operations to the local transactions. Checkpointing does not terminate the global transaction and the local transactions. Therefore, the GTM keeps its internal data structures. If a LDBS aborts a local (sub)transaction unilaterally, the GTM is notified by the corresponding LDA. In the current implementation the GTM aborts the global (sub)transaction by aborting all involved local (sub)transactions and raises an exception. Global deadlocks which are detected by timeouts in our implementation are handled in a similar way. To reduce the probability of failed validations, the ticket values could also be obtained at the beginning of a a local transaction. Because most commercial database systems use two-phase locking as concurrency control technique, this would lead to the direct serialization of all local interoperable transactions at the ticket object and, thus, would dramatically limit transaction throughput. Therefore, the GTM takes the tickets at global commit time by default. On the other hand, if a LDBS uses timestamp ordering as concurrency control policy it is better to obtain the tickets at this LDBS 15

16 when the local transaction is started [GRS94]. To take account of the special characteristics of an LDBS, the GTM can be configured to take the ticket at the beginning of a local transaction for a particular LDBS. 6 Related Work and Conclusions We have shown in this paper how global transaction management can be performed in an ODMG-compliant MDBS. All transactional commands of ODMG-93 are supported. It has been shown in detail how the nested structure of a global interoperable transaction trees is mapped to several local interoperable transaction trees. Global serializability is achieved by the ticket method. In contrast to [HAD97], taking a single ticket for each local interoperable top-level transaction is sufficient which simplifies the global transaction management enormously. Various approaches for the management of flat global transactions in MDBS have been described in the literature. The proposed approaches deal with the global serializability problem in presence of design and execution autonomy of the participating database systems [BGMS92, ZE93, BS88, GRS91, GRS94]. We utilize the ticket method which guarantees global serializability by the explicit introduction of local conflicts between global transactions [GRS94]. Other solutions for nested global transactions are multilevel transaction management [Wei91] which requires the specification of conflict semantics on the global layer, the DOM transaction model [BOH + 92], and the Interbase transaction model [ELLR90]. All these approaches are not applicable for ODMG-compliant MDBS because they require extensions of ODL and the ODMG transaction model to capture the additional semantics like compensation operations or commutativity specifications. As discussed in [HAD97], to allow for sibling intra-transaction parallelism, the GTM would have to obtain tickets for all local (sub)transaction that are executed in parallel. Thus, in case of parallel subtransaction, a global transaction takes multiple tickets from a single local database. This has to be considered in the global serialization test. For the approach presented in this paper, a single ticket per local database is sufficient due to the fact that the ODMG standard does not support intra-transaction parallelism. Nested transactions have also become part of OMG's common object service specification. OMG's transaction specification [OMG94] service supports nested transactions along with flat transactions based on the CORBA architecture [OMG91]. The solution presented in this paper (including the architecture of the GTM) could also be used to guarantee global serializability among several OMG transaction service managers that still execute local autonomous transactions. Acknowledgements The authors would like to thank all members of the IRO-DB team in Darmstadt for many inspiring discussions on the topic. Special thanks are due to Arnd Empting who helped in implementing the global nested transaction management within the IRO-DB system. 16

17 References [BE96] O. A. Bukhres and A. K. Elmagarmid, editors. Object-oriented Multidatabase Systems. Prentice-Hall, [BFHK94] R. Busse, P. Fankhauser, G. Huck, and W. Klas. IRO-DB: An objectoriented approach towards federated and interoperable dbms. In Proceedings of the International Workshop on Advances in Databases and Information Systems (ADBIS'94), May Moscow, Russia. [BGMS92] Y. Breitbart, H. Garcia-Molina, and A. Silberschatz. Overview of multidatabase transaction management. VLDB Journal, 1(2), [BOH + 92] A. Buchmann, M. T. Özsu, M. Hornick, D. Georgakopoulos, and F. A. Manola. A transaction model for active distributed objects systems. In Elmagarmid [Elm92], chapter 5, pages [BS88] Y. Breitbart and A. Silberschatz. Multidatabase update issues. In Proc. of the ACM SIGMOD Conference on Management of Data, June [Cat94] R.G.G. Cattell. The Object Database Standard: ODMG-93. Morgan Kaufmann Publishers, Inc., [Cat96] [ELLR90] [Elm92] [Geo91] [GFF97] R.G.G. Cattell, editor. The Object Database Standard: ODMG-93, Release 1.2. Morgan Kaufmann Publishers, Inc., A. K. Elmagarmid, Y. Leu, W. Litwin, and M. Rusinkiewicz. A multidatabse transaction model for interbase. In Proc. of the 16th Int. Conference on Very Large Databases, pages , Brisbane, Australia. A. K. Elmagarmid, editor. Database Transaction Models for Advanced Applications. ACM Press. Morgan Kaufmann Publishers, Inc., D. Georgakopoulos. Multidatabase recoverability and recovery. In Proc. of the first Int. Workshop on Interoperability in Multidatabase Systems, G. Gardarin, B. Finance, and P. Fankhauser. Federating object-oriented and relational databases: The IRO-DB experience. In Proc. of the second IFCIS Int. Conference on Cooperative Information Systems, June [GGF + 96] G. Gardarin, S. Gannouni, B. Finance, P. Fankhauser, W. Klas, D. Pastrea, R. Legoff, and A. Ramfos. IRO-DB: A distributed system federating object and relational databases. In Bukhres and Elmagarmid [BE96], chapter 20, pages [Gra78] [GRS91] J. Gray. Notes on data base operating systems. IBM Research Report RJ2188, IBM, San Jose, California, D. Georgakopolous, M. Rusinkiewicz, and A. Sheth. On serializability of mulitdatabase transactions through forced local conflicts. In Proc. of the seventh IEEE Int. Conference on Data Engineering, pages ,

18 [GRS94] [HAD97] [Kim95] [Mos82] D. Georgakopoulos, M. Rusinkiewicz, and A. P. Sheth. Using tickets to enforce the serializability of multidatabase transactions. IEEE Transactions on Knowledge and Data Engineering, 6(1), February U Halici, B. Arpinar, and A. Dogac. Serializability of nested transactions in multidatabases. In Proc. of the sixth Int. Conference on Database Theory, Delphi, Greece, January W. Kim, editor. Modern Database Systems: The Object Model, Interoperability, and beyond. Addison-Wesley Publishing Company, J. E. B. Moss. Nested transactions and reliable distributed computing. In Proc. of the IEEE Symposium on Reliability in Distributed Software and Database Systems, [MRKS92] S. Mehrotra, R. Rastogi, H. F. Korth, and A. Silberschatz. Relaxing serializability in multidatabase systems. In Proc. of the second IEEE Int. Workshop on Research Issues on Data Engineering, pages , February Tempe, Arizona. [OMG91] Object Management Group OMG. The Common Object Request Broker: Architecture and Specification. OMG Document, [OMG94] Object Management Group OMG. Object Transaction Service. OMG Document, [RFFS95] A. Ramfos, J. Fessy, B. Finance, and V. Smahi. IRO-DB: A solution for computer integrated manufacturing applications. In Proceedings of the third International Conference on Cooperative Information Systems (CoopIS-95), pages , May Vienna, Austria. [SL90] [TWL95] [Vei90] [Wei91] [ZE93] A. P. Sheth and J. A. Larson. Federated database systems for managing distributed, heterogeneous, and autonomous databases. ACM Computing Surveys, 22(3), T. Tesch, J. Wäsch, and W. Lu. Design specification for the global transaction management in IRO-DB. Technical Report IRO/SPEC/GMD/D4-6.1-V1.1, ESPRIT Project P8629, October J. Veijalainen. Transaction Concepts in Autonomous Database Environments. R. Oldenbourg Verlag, G. Weikum. Principles and realization strategies of multilevel transaction management. ACM Transactions on Database Systems, 16(1): , A. Zhang and A. K. Elmagarmid. Theory of global concurrency control in multidatabase systems. VLDB Journal, 2(3),