Atomic Commitment for Integrated Database Systems

Transcription

1 Atomic Commitment for ntegrated Database Systems Peter Muth Thomas C. Rakow GMD ntegrated Publication and nformation Systems nstitute (PS) Dolivostrasse 15, D-6100 Darmstadt, West Germany { muth, rakow darmstadt.gmd.dbp.de Abstract The integration of existing databases provides for a uniform access to data stored by different database systems. Besides the integration of different data models and query languages, transaction management has to be provided. n this paper, we present a systematic discussion of atomic commitment for heterogeneous database systems. n homogeneous distributed systems, two phase commit is the most commonly used protocol. t uses a ready state for local transactions in order to wait for the global commit or abort decision. n heterogeneous systems, the use of a ready state is not feasible, since this requires all participating existing transaction managers to provide that state. We analyze two altemative protocols for atomic commitment: commitment of local transactions after or before the global commit or abort decision is made. The impact of the protocols to recovery and concurrency control is shown. We demonstrate that commitment before fits best to multi-level transactions. n this case, the commitment protocol causes no additional overhead and a higher degree of concurrency can be achieved. 1 ntroduction The need for a uniform access to information stored in different databases has grown rapidly during the last years. n most organizations today, a user has to deal with many different database systems, using different data models and different query and update languages. The results of queries against different databases have to be combined manually. n order to solve these problems, the integration of different database systems is needed, making differences between the existing database systems invisible and providing users with a uniform access to all the databases. The integration of several database systems will result in adistributed, heterogeneous database system. Many researchers have focused their work on the data model and the query and update language of such a system [LR 82, TBC 87, NS 88, KDN 901. Others focus on transaction management [BS 88, BST90, DE 89, DEL 89, GS 87, LT 89, Pu 88, WV 901. A global transaction in an integrated database system.is executed by the different existing database systems. Hence, the global transaction management has to deal with different existing transaction managers, i.e. different interfaces, different protocols and different concurrency control and recovery methods. Most of the existing transaction managers were not designed to participate in aglobal environment. Still, the aim ofglobal transaction management for integrated database systems is to provide global transactions with the ACD properties: atomicity, consistency, isolation and durability [HR 831. n contrast to federated database systems [DE 871, the user need not consider the distributed execution of a transaction. n this paper, we focus on atomic commitment of transactions in the integrated system. The various solutions for homogeneous systems are not appropriate for heterogeneous systems, since they require specific commit procedures which are not provided by most of the existing transaction managers. We figure out why these procedures cannot be added later on, and we systematically discuss two altemative protocols which do not require changes of the existing transaction managers. The first protocol requires additional concurrency control and recovery components to be implemented on top of the existing database systems [BST 90, WV 901. Since these components cause additional runtime overhead, we developed a second, altemative protocol. f multi-level transactions are used for the heterogeneous system, our protocol reuses the concurrency control and recovery mechanisms of this transaction model in order to provide an atomic commitment for global transactions. Multi-level transactions have originally been developed to increase the degree of concurrency in non-distributed, homogeneous database systems [BBG 89, RGN 90, Wei 861. We describe the adaptation of this transaction model to a heterogeneous environment and compare both atomic commitment protocols. The main contributions of our protocol are (1) a higher degree of concurrency and (2) no additional overhead, if used together with multi-level transactions. The remainder of the paper is organized as follows. n section 2, the architecture of integrated database systems as used in this paper is defined. Section 3 gives a brief description of the two phase commit protocol as used in homogeneous distributed database systems. Thereafter, two altemative protocols for atomic commitment in a heterogeneous, distributed database environment are discussed. n section 4, we describe the adaptation of multi-level transactions for integrated, heterogeneous systems and the advantages and drawbacks of the two altemative protocols to atomic commitment in this environment. Section 5 briefly compares our approach to related work and section 6 concludes the paper. 2 System Architecture n this section, we first describe the definition of global and local transactions in our system. After that, we define the control and data flow between subsystems. The system modules which implement the defined transaction and communication architecture are described. All discussions in the subsequent sections will rely on these definitions. n most cases, the existing database systems will reside on more than one site of a network. The goal is to make all existing databases available to the users through a global, integrated system. CH2968-6/0000/0296$01.OO Q 1991 EEE 2% 1

2 With respect to this aim, and in order to facilitate consistent maintenance of the whole distributed system, a hierarchical approach is usually applied. A central database system is responsible for the coordination of global transactions. n addition, the central database system stores all the global data which are needed for the integration of the existing systems, e.g. information for schema integration. According to this information, a global user transaction will be decomposed into local transactions. The local transactions are executed by the existing database systems. network Transaction Manager 1 central system local system. local system Communication Communication Communication Manager Manager Manager DBMS DBMS DBMS -- n -- Transaction Transaction Transaction n n Figure 1: System Architecture Local transactions must not start subtransactions in other existing database systems, since this would violate global control. n addition, local transactions which are not under control of the central system are not allowed, as global serializability is very hard to achieve without a common global control [GP 86, BS 88, DE 89, DEL 891. n order to reflect the transaction structure by means of communication, all the existing systems are directly connected to the central system But in many cases, the existing systems are not designed to participate in a global environment. Hence, a communication manager on top of such a system is needed. The local communication managers listen on the net for global calls, and pass them to the existing database systems. On the way back, the local communication managers package information available at the interface of the existing database system into network messages and data, and send it to the central system. The communication manager of the central system is the counterpart of the local communication managers. The control and data flow can be characterized by the following properties (Figure ): The central system may send messages and data to the local systems. Local systems respond to the messages of the central system and send status information and data back to the central system. Local systems do not communicate directly with each other. This communication scheme is sufficient to provide all the communication facilities needed by transactions in our system. For each of the existing systems, only a single connection to the central system is needed. As a consequence, the integration of additional systems into the existing heterogeneous environment does not cause further problems affecting the already integrated existing database systems. We do not make any assumptions about the internal architecture of the existing systems or the central system. Both types of systems may be distributed or non-distributed. We only demand each of the existing systems to have a transaction management. t has to ensure ACD properties for its transactions. n order to make the transaction management of each existing system available for global transactions, the corresponding interface has to provide calls for "begin", "abort" and "commit" of a transaction. 3 Atomic Commitment An evident requirement to provide global ACD transactions is atomic commitment [BHG 87, CP 84, NW 821. n general, a global transaction is atomically committed or if all its subtransactions in the local databases follow the same global decision, i.e., they all commit or they all abort. The most commonly usedprotocol for atomic commitment is the two phase commit protocol [Gra 781. Unfortunately, it has to be implemented inside of the participating transaction managers. This is not applicable for heterogeneous architectures, because the existing local transaction managers cannot be changed. n this section, we describe the two phase commit protocol as used in distributed database systems and two altemative protocols, which do not require changes of the existing transaction managers. Common to all protocols, the global transaction manager makes the global commit or abort decision. The approaches differ in the commit point of local transactions with respect to the point of time the global decision is made. 3.1 Two Phase Commit To start the two phase commit protocol, the global transaction manager sends a "prepare" message to all local transactions. The local transactions try to become ready to commit, i.e. reach the ready state. n this state, a local transaction has successfully finished all its actions. To be able to follow a global commit decision, the changes of the local transactions are written to stable storage. Different to the committed state, it is still possible to abort a local transaction in the ready state. n other words, the local transaction is definitely able to follow a global commit or abort decision. When a local transaction has reached the ready state, it sends a "ready" message to the global transaction manager (Figure 2). Otherwise, the local transaction is and an "abort" message is sent. After the global transaction manager has received all the "ready" or "abort" messages, the global decision is made. f the decision is commit, i.e. all local transactions are in the ready state, a "commit" message is sent to all local transactions. f the decision is abort, an "abort" message is sent. After all the local transactions have followed the decision, and, in case of a global commit decision, the global transaction manager has received the "finished' messages from the local nodes, the protocol is finished. The basic idea of two phase commit is the definition of the ready state. n comparison to non-distributed systems, switching from the running state to the ready state is the beginning of the commit procedure: all actions are finished and all changes of the transaction are written to stable storage. After that, the two phase commit protocol continues differently from non-distributed com- 297

3 Transaction states of the global transaction Messages Transaction states of a local transaction A A inquire waiting to commit/ ready / commit / abort ready/ committed/ mit procedures. The commit procedure is interrupted in order to find the global decision. After the decision is made, the final commit is done, e.g. releasing the locks of a lock-based concurrency control. From this point of view, the decision is made in the middle of the commit procedure of the local transaction (Figure 3). Neither does the commit precede the decision, nor is the decision made before the local commit started. This way of making the global decision and commitment is obviously a solution for the atomicity problem. f the commit is not done before the global decision is known, an erroneous commit of a local transaction which must be later on will not occur. On the other hand, if the decision is not made before it is sure that all local commits will eventually finish, it is not possible that a global commit will fail after the decision to commit is made. Figure 2: States and messages of two phase commit W Figure 3: Deciding in the middle of the commitment Unfortunately, this scheme is also thereason why it is impossible to use two-phase commit with most of the existing transaction managers. The interface of these managers doesn t provide a ready state. Hence, the state transition from running to committed is atomic, i.e., it cannot be interrupted by the wait for the global decision. Therefore, all atomic commit protocols which make use of standard transaction managers will not be able to make the global decision in the middle of the commitment of the local transactions. Two alternatives to solve this problem are possible: commitment of local transactions after or before the global decision is made. We discuss both altematives in the following sections. 3.2 Local Commitment After Global Decision n this section, we describe how atomic commitment is achieved if the global decision is made before the local transactions started to commit. The protocol is based on two phase commit, but a ready state for the local transactions is not used. nstead, the communication manager on top of each local database system answers to the prepare call immediately after the according local transaction has finished its last action. Like in the two phase commit protocol, a ready or abort message is sent. The global transaction manager decides to commit if all local communication managers sent a ready message, otherwise the decision is to abort the global transaction. After the decision is received by the local systems, the local transactions will be committed or. n case of commit, a finished message is sent to the global transaction manager after the local commit is completed. n the absence of failures, this protocol causes the same result as two phase commit: The distributed transaction is atomically committed. A problem occurs if a local transaction is after it has sent its ready message. Different to two phase commit, such an abort is possible, because the local transaction waits for the global decision in the running state. Hence, the transaction may still be by the local transaction manager, e.g. because of time out, by an optimistic scheduler since the transaction did not survive the validation phase, or by a system crash. n either case, the atomicity condition for the global transaction is violated if the global transaction manager has decided to commit and other subtransactions of the global transaction have successfully been committed. We are not able to prevent such a situation, but we can react after the situation has occurred. f the local transaction is after it has sent its ready message, it must be repeated. The repetition ensures atomicity of the global transaction, because all local transactions will be in the committed state after the repetition has finished. Of course, an abort may also occur during the repeated execution of the transaction. n this case, the transaction has to be repeated again. What about the possibility of an infinite loop of repetitions? -The first execution of the transaction was completely executed except its commit. Therefore, a repeated execution will not be due to the transaction logic, e.g. a division by zero. Neglecting a malfunction of the database system, the transaction is definitely able to reach the committed state. Figure 4 shows the state transitions of both global and local transactions and the exchange of messages. Since local transactions 298

4 Transaction states of the global transaction Messages Transaction states of a local transaction running inquire "prepare" \ "ready"/ running waiting waiting to commit/ "commit"/ "abort" committed/ ning "finished" committed 4r----- Redo execution of the local transaction Final committed state of local transaction Final state of 9 local transaction Figure 4: States and messages of local commitment after global decision are repeated in case of erroneous local aborts, the local transaction may be executed several times in the according database system. The small circles represent the states of these transactions. But not all of the possible final states are valid from the point of view of the global transaction. Valid final states are surrounded by a larger circle. A vertically hatched circle represents a final committed state of the local transaction, a horizontally hatched circle represents the final state. A double arrow indicates the restart of a transaction in the database system. A local transaction is committed if the first run is committed in the existing database, or if one of the repetitions is committed. The corresponding states are represented by the vertically hatched circles. The state of the first run, represented by a horizontally hatched circle, is a valid final state for the local transaction if it intended to abort. Otherwise, the transaction is after it has sent the "ready" message and has to be repeated. n this case, the state diagram follows the double arrow to start the repetition. The state of arepeated transaction is not a valid final state of the local transaction, since the protocol repeats the transaction until it finally commits. commit W Figure 5: Local commitment after global decision The need for redoing a local transaction is directly caused by the fact that the global decision is made before the local transactions committed, as shown in Figure 5. Hence, we define the following requirement: Redo requirement for commitment after: A recovery mechanism to redo local transactions is needed. Redo of erroneously local transactions also impacts serializability. The serialization order of local transactions on a given node must not be changed if a local transaction is repeated. Assume a local transaction T has read object x and a "ready" message has been sent by the communication manager on top of the local database system. Further assume, a second local transaction T? wants to change x afterwards. The local and global serialization order will be T + T?. f T is erroneously before it has finally committed, TZ may be executed before T is repeated. The repeated execution of T will read the new value of x, and therefore the serialization order of T and TZ has changed to TZ -+ T. This will change the global serialization order, too. n some cases, changing the order will cause a cycle in the serialization graph of the global transaction, and the whole global transaction has to be. Obviously, an abort is impossible since local subtransactions have already been committed. n addition to the redo requirement, the following requirement for serializability must be fulfilled: Serializability requirement for commitment after: The global serialization order determined by the first execution of a local transaction must not be changed in case of a repeated execution of this transaction. n order to implement the protocol, a redo-log for the repeated execution of local transactions is needed. The redo-log contains the actions of the global transaction. The commit of a local transaction must be propagated to the redo mechanism which implements the redo-log, since a committed local transaction must no longer be redone. n addition, committing the local transaction and propagating the commit to the redo mechanism must be executed atomically. Otherwise, if the system crashes the following erroneous situations may occur. (1) f the system crashes between the commit and the propagation, the recovery mechanism will assume that the local 299

5 a global transaction ning A Transaction states of the running inquire Messages prepare abort running mitted/ Transaction states of a local transaction committed/ waiting ~ undo to abort + finished l4----i undo Undo execution Final committed state of e Final state of the local transaction local transaction local transaction Figure 6: States and messages of local commitment before global decision transaction has been and will erroneously repeat it. (2) A crash after propagation but before the commit will result in no repetition at all, even though a repetition is necessary. Hence, the redolog must either be written into the existing database by the local transaction, e.g. as an additional relation [WV 901, or the redo-operations must be idempotent. An additional concurrency control component is used to prevent a violation of the global serialization order by repeated execution of the local transactions. That is, in case of an erroneous abort of a local transaction, no conflicting local transaction must be executed before the repetition has succeeded. Therefore, the additional concurrency control module controls the submission of local transactions. n comparison with two phase commit, the overhead of the proposed protocol is much higher due to the additional concurrency control and recovery components. But the protocol allows the integration of unmodified transaction managers of existing systems. A ready state is no longer needed, and the additional components can be implemented on top of the existing systems, or as a part of the global transaction manager. Together with a communication component, which implements the communication protocol on top of the existing systems, these components implement the atomic commitment protocol. 3.3 Local Commitment Before Global Decision n this section, a protocol using the opposite strategy of the above protocol is discussed: local transactions are committed before the global decision is made. The local transactions may commit or abort independently of the global transaction manager. The global transaction manager asks for the final state of each local transaction by sending a prepare message. Two different cases have to be considered. f all local transactions have either committed or, the global transaction manager does not need to start further actions in the local systems. f some local transactions and some committed, all the committed transactions have to be un- 300 done. This is achieved by sending an undo message from the global transaction manager to the local systems and waiting for the finished message in order to terminate the protocol. Different to thepreviousprotocols, where the global transaction waits to finally commit (waiting to commit), the global transaction now waits for the global abort (waiting to abort). n contrast to the previous protocol, there is no difference whether the local abort was caused by the local transaction, by the system, or by a crash. The global transaction manager simply waits for all the communication managers to answer to the prepare message. f a local system crashes before the local transaction has committed, the global transaction manager has to wait for the local system to come up again. After the local recovery is finished, the local transaction is in the state, and the answer to the prepare message is abort. Figure 6 shows the state transitions of both global and local transactions, and the exchange of messages between them. Again, the hatched circles represent final states of the local transaction. As in the approach of section 3.2, the complete execution of a local transaction may consist of the execution of more than one transaction in the according existing local database system. This is the case if the changes of a locally committed transaction have to be undone by another transaction, i.e. by its inverse transaction. Such an undo is necessary due to a global abort decision. Therefore, in Figure 6 a double arrow connects the committed state of the local transaction with the running state of the according inverse transaction. The inverse transaction may also commit or abort. n case of a commit, a final state for the local transaction is reached. Obviously, in case of abort it has to be repeated. The same question as in the discussion of the previous protocol arises: What about the possibility of an infinite loop of repetitions? - t is assumed that the inverse transaction of the committed transaction will not be due to its logic, analogously to the previous approach. Hence, a repeated inverse transaction will eventually commit. J 1

6 commit W Figure 7: Local commitment before global decision Even though a successful inverse transaction is in the committed state, the whole local transaction is in the state! This is due to the fact that committing of undo means aborting the local transaction, represented by the vertically hatched circle around the committed state. The need for undoing a local transaction is directly caused by the temporal sequence of local commitment and global decision (Figure 7), which is reversed in comparison to the previous protocol (Figure 5). According to the requirements of the previous section, this protocol can be characterized by the following two requirements: Undo requirement for commitment before: A recovery mechanism to undo local transactions is needed. Again, the problem of global serializability has to be solved. n the previous protocol we had to consider the serialization order of the redo transaction and the other local transactions. Now, the serialization order of the undo transaction and the other local transactions is of interest. For example, assume that a local transaction T changed object x and committed. Afterwards, x is read by a transaction Tz. f T is undone now by restoring the old value of x, the value read by Tz becomes obsolete. Serializability requirement for commitment before: A local transaction must not occur in the serialization order between an erroneously committed transaction and its inverse transaction if this makes the inverse transaction unable to undo the changes of the erroneously committed transaction. This requirement is fulfilled if no transaction must occur in the serialization order between an erroneously committed transaction and its inverse transaction. But, if the semantics of local transactions is considered, some local transactions might be allowed to occur between them. This is the case for multi-level transactions as described in the next chapter. n order to implement the protocol, an undo-log for the repeated execution of local transactions is needed. Since the undo operations are executed as local transactions, the commitment of an undo transaction and the propagation of the commit must be atomic. Due to the same reasons as mentioned in the previous approach, a system crash between the commit and the propagation may otherwise cause a local transaction to be doubly undone. A crash between the propagation and the commit will cause the transaction to be not undone at all. The alternatives of the previous section are applicable again. We can write the undo-log by the local transaction as new data that is to be stored in the existing database, or we can provide the property of idempotence for the undo operations. n addition to the undo-log, a new concurrency control module is needed. t has to ensure that no local transactions (or some local transaction if the semantics is considered) will read or change data that was changed by other transactions which are not globally committed. Like the previous protocol, this scheme does not require any modifications to the local transaction managers. Both the undo-log and the additional concurrency control can be implemented on top of the existing systems or in the global system. The undo-log stores inverse transactions, derived from the original global transactions. The additional concurrency control module controls the submission of local transactions to the existing database systems with respect to the serializability requirement. The most important difference between committing before the global decision is made and committing after the global decision is related to concurrency. Let us assume that a locking scheme for local transactions is used. After a local transaction is committed, its locks are released. f the local commit is done after the global decision is made, i.e. at the end of the global transaction, all the local locks are held until the end of the global transaction. f the local commit is done before the decision is made, the local locks are released at the end of the local transaction, i.e. before the end of the global transaction. Even in presence of the serializability requirement for transaction undo, the degree of concurrency can be increased using multi-level transactions as described in the next chapter. 4 Multi-Level Transactions in ntegrated Database Systems n this section, a transaction model for global transactions in integrated, heterogeneous database systems (Figure 1) is discussed. Since the composition of the existing local systems and the global central one is done in a hierarchical fashion, a hierarchical transaction model is appropriate. We propose the use of multi-level transactions and describe the combination of this transaction model with the two proposed atomic commitment protocols. 4.1 Multi-Level Transactions Multi-level transactions, as a special case of open nested transactions, have initially been designed to provide for an increased degree of concurrency in central database systems [BBG 89, RGN 90, Wei 861. A multi-level transaction consists of separate transactions at different levels of abstraction. The topmost level, i.e. the level of the transaction defined by the user, is said to be level L,. The bottom level, e.g. the page level, is denoted level LO. Each action at level L, is executed as a subtransaction at level L,-,. The semantics of L, actions are reflected in the definition of an L, conflict. Two L, actions al and a2 are in conflict if they do not generally commute, i.e., if there exists a database state in which the results of the sequence al;az and the sequence a2;al are different. Each level has to ensure the atomicity constraint for its transactions. Hence, the actions at the next upper level are atomic. Under this condition, the implementation of L, (0 < i n) actions, i.e. L,- transactions, can be disregarded. At the bottom level LO, actions are atomic by definition, e.g. page operations. f all schedules at all levels L, (0 i n) are serializable, the whole multi-level transaction is serializable [Wei 861. Serializability may be ensured by a two phase locking protocol. For each level L,, L, locks are granted according to the conflict definition between Li actions. f a transaction at level L, is finished, its locks are released. The release increases the degree of concurrency in comparison to single-level transactions, because Li locks are held only during the execution of an L, transaction. After the execution is finished, other Li transactions may get the locks, they do not have to wait until the L,,, transaction is finished. Serializability 301

7 T1 T2 c ncr (x) ncr (x) ncr(y) EOT EOT (L1) R (p) w (P EOT R (p) W (p) EOT R (p) W (p) EOT (Lo) EOT = End of transaction L 1 Figure 8: Two-Level 'hansactions at level L,,, is ensured by L,+ locks, which prevent the concurrent execution of L, transactions that represent conflicting L,+ actions. For example, consider the commuting increment operations at level L1 shown in Figure 8. Both transactions T1 and T2 get the increment locks on object x. Consistent access to page p which stores x is ensured by the LO concurrency control. The increased degree of concurrency is caused by the short LO transactions that implement the page access. For single-level transactions, the degree of codcurrency is lower, since page level locks are held until the end of the transaction. n addition, the increment lock on object y is granted, too. Again, this is not possible for single-level transactions, because x is stored on the same page p as y. For multi-level transactions, consistent access to page p is ensured again by the concurrency control. The price for the increased degree of concurrency has to be paid by the recovery [KLS 90, Wei 84, WHBM 901. f the system crashes during the execution of a multi-level transaction, undo operations have to be performed. Undoing a transaction at level L, by restoring the L,_l state to the state before the L, transaction has started is not feasible, because other L,- subtransactions of a different L, transaction may have been executed in the meantime. Restoring the previous L,-l state will also destroy their changes. Consider again Figure 8. Assume, T1 is after T2 has finished the increment of x. f T1 is by restoring the previous value of x, e.g. by using the before image of page p, the increment of T2 will also be lost. The problem is due to the fact that the page-level locks (LO) are released before the according L, transaction is finished. The solution is to undo a transaction by executing inverse actions. n the example above, the increment will be undone by executing a decrement. n this case, the increment of the second transaction will not be affected by the undo. n general, at each level L, an action is undone by executing the according inverse L, action, i.e. an L,+, subtransaction. From the concurrency control and recovery point of view, inverse actions are treated as normal actions. They may run concurrently with other actions, and in the simplest case the recovery logs 'inverse of inverse actions'. Optimizing the execution of inverse actions is not considered in this paper. 4.2 Transaction Levels in ntegrated Database Systems f multi-level transactions are used in heterogeneous systems, another advantage becomes important: The independence of the schedulers and recovery modules at each level. n order to provide ACD transactions at the topmost level L,, it is sufficient to provide ACD transactions at each level L, (0 i n) [Wei 861. By the scheme described above, this can be achieved for each level separately, i.e. without information from other levels. The integration of transactions of the existing systems becomes possible. The existing transaction managers can be integrated as transaction managers for transactions at level Lo, since they provide the ACD properties for their transactions. According to the architecture shown in Figure 1, we define two transaction levels: (1) level L: Global transactions, defined by the user and executed by the central system (2) level Lo: Local transactions, executed by the existing transaction managers. Serializability of L transactions is provided by the concurrency control of the transaction manager in the central system. A recovery component which is responsible for the undo of L actions by executing inverse actions is also included in the central transaction manager. Concurrency control and recovery for LO transactions are provided by the transaction managers of the existing systems. 4.3 Atomic Commitment with Multi-Level 'hansactions n this section, we discuss the problem of atomic commitment with respect to multi-level transactions. n order to evaluate the usefulness of the two approaches discussed in sections 3.2 and 3.3, we have to take into account the effort needed to implement a specific protocol, the resources it consumes during runtime, and the performance of the commit procedure. Commitment after the decision is made n order to determine the effort needed to implement the commitment after protocol, we first have to consider the additional concurrency control and recovery components. Since the recovery manager for transactions at level L1 only provides undo-logging (of inverse actions), the redo log has to be implemented in addition to the undo-log. The redo-log module will satisfy the redo requirement. The concurrency control component assigned to level L can be used to ensure serializability in case of repeated execution of local subtransactions. t holds all the global Ll locks until the L transaction is finished. Conflicting L1 actions, i.e. Lo subtransactions that would make a repetition of erroneously LO transactions impossible, are not submitted due to the conflict definition of L actions. Hence, a repeated execution of Lo transactions is possible until the L transaction is finally committed. This exactly fulfils the serializability requirement. The overhead of recovery during runtime may slow down the system significantly, as two kinds of logs, a redo-log and an undo-log, have to be maintained. The performance during the commit procedure depends on the likelihood of transaction repetition. Repeated execution is only necessary in case of erroneously subtransactions. Hence, in the absence of failures, the commit protocol performs very well. f local transactions have to be repeated frequently, performance decreases. Commitment before the decision is made This protocol needs specific concurrency control and recovery components, too. But different to the previous approach, the undo 302

8 and serializability requirements of thecommitment before protocol are already fulfilled by components of the transaction manager of level L1. Undo of committed subtransactions is included in the concept of multi-level transactions. n case of an abort of a transaction at level L1, the according committed LO subtransactions have to be undone. As described above, this is done by executing inverse L actions, i.e., Lo transactions. Hence, the Ll undolog can be used to undo local Lo transactions which have to be undone due to the global decision. Different to the previous protocol, no redo-log is required. The serializability requirement for commitment before is fulfilled by an inherent property of multi-level transactions. Assume, strict two phase locking is used for both levels L and LO. For example, an LO transaction T2 occurs in the serialization order between another transaction T and its inverse transaction T -', i.e., the serialization order is T + T2 -+ T -. Assume, the execution of T2 makes T -' unable to undo the changes of T. n this case, the serializability requirement would not be fulfilled. We show that, dependent on the semantics of T and T?, eithe the schedule T + T -+ T is not valid, or T? will not make the undo of T by T-' impossible. Firstly, we assume that the according L actions oftl and T2, A and A2, do not commute. n this case, the L concurrency control would have delayed A2, i.e. T2, until the Ll transaction of A has committed or. As a consequence, T2 could not have been scheduled before T -. The considered schedule is shown to be invalid. Secondly, we assume that A and A2 commute. Hence, theresult at level L1 will be the same as if the following Lo serialization order occurred: T2 + T -+ T -. n this schedule, T is obviously undone by T without problems, since no immediate LO transactions between T and T - occur. During runtime, the atomic commit protocol causes no additional overhead. All the concurrency control and recovery overhead is already included in the transactionmanagement of the L level. Most important, the increased degree of concurrency caused by the release of Lo locks at the end of each LO transaction is not affected by commitment after the global decision. Since local transactions commit without waiting for the global decision or any other message from the global transaction manager, the commitment of Lo subtransactions is not delayed by the protocol. Hence, the release of Lo locks is also not delayed and the higher degree of concurrency induced by the use of multi-level transactions is obtained. Validation of both alternatives The significant drawback of commitment after global decision is runtime performance. LO locks are held until the end of the according L1 transaction. The most important advantage of multi-level transactions, the release of L, locks before the L,+ transaction is finished, has been lost. Due to this fact, the higher degree of concurrency available through multi-level transactions is lost if commitment after is used. The only drawback of commitment before global decision is the overhead in case of an intended local transaction abort. n this case, the whole global transaction has to be and already committed local transactions have to be undone by the use of in- verse transactions. ntended transaction aborts are handled better if local transactions are committed after the global decision is made. n this case, the global abort decision is sent while all local transactions are in the running state, and therefore the local transactions can be easily without the use of additional recovery components. On the other hand, there exist two main advantages of committing local transactions before the global decision. (1) No additional concurrency control and recovery modules are needed to integrate the protocol into multi-level transactions. (2) The higher degree of concurrency of multi-level transactions remains to be available. Hence, the combination of commitment before with multi-level transactions is superior to commitment after. 5 Related Work Research in the field of distributed transactions mostly addresses homogeneous database systems. The basic work was done years ago. [CP 841 and [BHG 871 give an excellent summary of recovery and concurrency control issues, including various approaches to atomic commitment. Almost all of them are based on two phase commit [Gra 781. which is the most commonly used protocol. A complete generation of derived protocols improve two phase commit in many directions, e.g., with respect to blocking of participants [Ske 811, or to the complexity in terms of writes to the log [ML 831 and of communication [DS 831. But the more complicated the protocol, the bigger the amount of modifications of existing transaction managers which are needed to implement it. Only a few researchers have addressed atomic commitment under the prerequisite of unchangeable local transaction managers [BST 90, WV 901. These protocols can be classified as approaches of local commitment before global decision. Additional concurrency control and recovery components are implemented on top of the existing systems. We have developed a different protocol, and to the best of our knowledge, this protocol and its combination with multi-level transactions has never been described elsewhere. Two similar transaction models for heterogeneous database systems, which also use two transaction layers, are discussed in [AGK 87, GS 871. The first scheme is called sagas. Compensating local transactions are used to undo committed local transactions, but global serializability is not ensured. The second scheme uses altruistic locking in order to provide global serializability. The goal of altruistic locking is the early release of locks without violating serializability. Compared to multi-level transactions, a more complicated algorithm maintaining dependencies between transactions is used. 6 Conclusions We have presented a systematic description of atomic commitment protocols for integrated, heterogeneous database systems. The protocols have been classified with respect to the sequence of the local transaction commit point and the point of time the global decision is made. We compared a well known approach with our new approach of committing local transactions before the global decision is made. Both do not require changes of the transaction managers of the existing systems. We adapted multi-level transactions for the heterogeneous environment. By the use of this model, we achieved ACD properties for global transactions. Both alternatives for atomic commitment in the heterogeneous environment have been checked for their usefulness together 303

9 with multi-level transactions. t has been shown that our new approach of committing local transactions before the global decision is made fits best with multi-level transactions. The concurrency control and recovery modules needed by multi-level transactions are reused by the protocol. Due to this fact, no runtime overhead is caused by the atomic commitment protocol. Compared to other approaches, this is a major advantage. Furthermore, the degree of concurrency is increased in comparison to flat distributed transactions that use two phase commit, since, in our scheme, locks of local transactions are released before the end of the according global transaction. Currently, both the multi-level transaction model and our new atomic commitment protocol are being implemented in the objectorienteddatabase system VODAK, which is developed at our institute [DKT 88, KDN 90, Kla 90, KNS 88, NGPT 90, RGN 901. VODAK serves as the global database system for the integration of different existing systems. The usage of the commutativity of methods specified in an object-oriented data model gives us the ability to define less restrictive conflict relations between operations than read/write conflicts. Thereby, the increased degree of concurrency of multi-level transactions is used. For VODAK, the proposed atomic commitment protocol which does not impose further restrictions on concurrency is strongly needed. Acknowledgement Discussions with Wolfgang Klas and Erich J. Neuhold are gratefully acknowledged. [AGK 871 [BBG 891 [BHG 871 [BS 881 [BST 901 [CP 841 [DE 871 [DE 891 [DEL 891 [DKT 881 [DS 831 [Gra 781 References Alonso, R., Garcia-Molina, H., Salem, K.: Concurrency Control and Recovery for Global Procedures in Federated Database Systems. n [DE 871. Beeri, C., Bemstein, P.A., Goodman, N.: A Model for Concurrency in Nested Transaction Systems. Journal of the ACM, Vol. 36, No. 2, Bemstein, P. A., Hadzilacos, V.,Goodman, N.: Concurrency Control and Recovery in Database Systems. Addison Wesley, Breitbart, Y., Silberschatz, A.: Multidatabase Update ssues. Proceedings ACM SGMOD, Breitbart, Y., Silberschatz, A., Thompson, G.: Reliable Transaction Management in a Multidatabase System. Proceedings ACM SGMOD, Ceri, S., Pelagatti, G.: DistributedDatabasesPrincipfes and Systems. McGraw-Hill, Data Engineering, Special ssue on Federated Database Systems, Vol. 10, No. 3, Du, W., Elmagmid, A. K.: Quasi Serializability: a Correctness Criterion for Global Concurrency Control in nterbase. Proceedings VLDB, Du, W., Elmagarmid, A. K., Leu, Y. et al.: Effects of Autonomy on Maintaining Global Serializability in Heterogeneous Database Systems. Technical Report, Purdue University, Duchhe, H., Kaul, M., Turau, V.: VODAK Kemel Data Model. n Dittrich, K. R. (Ed.): Advances in Object-Oriented Database Systems. LNCS, No. 334, Springer, Dwork, C., Skeen, D.: The nherent Cost of Nonblocking Commitment. Proceedings ACM Symposium on Principles of Distributed Computing, Gray, J. N.: Notes on Database Operating Systems. Operating Systems: An Advanced Course. LNCS, No. 60, Springer, [GP 861 Gligor, V., Popescu-Zeletin, R.: Transaction Management in Distributed Heterogeneous Database Management Systems. nformation Systems, Vol. 11, No. 4, [GS 871 Garcia-Molina, H., Salem, K.: SAGAS. Proceedings ACM SGMOD, [HR 831 Harder, T., Reuter, A.: Principles of Transaction-0- riented Database Recovery. ACM Computing Surveys, Vol. 15, No. 4, [KDN 901 Kaul, M., Drosten, K., Neuhold, E. J.: Viewsystem: ntegrating Heterogeneous nformation Bases by Object-Oriented Views. Proceedings EEE Data Engineering, [Kla 901 Klas, W.: A Metaclass System for Open Object-Oriented Data Models. Dissertation, TU Wien, [KLS 901 Korth, H. F., Levy, E., Silberschatz, A.: A Formal Approach to Recovery by Compensating Transactions. Proceeedings VLDB, [KNS 881 Klas, W., Neuhold, E. J., Schrefl, M.: On an Object- Oriented Data Model for a Knowledge Base. n Speth, R. (Ed.): Research into networks and distributed application - EUTECO '88. North-Holland, [LR 821 Landers, T., Rosenberg, R.: An Overview of Multibase. n Schneider, H. J. (Ed.): Distributed Data Bases. North-Holland, [LT 891 Litwin, W., Tirri, H.: Flexible Concurrency Control using Value Date. n Gupta, A. (Ed.): ntegration of nformation Systems: Bridging Heterogenous Databases. EEE Press, [ML 831 Mohan, C., Lindsay, B.: Efficient Commit Protocols for the Tree of Processes Model of Distributed Transactions. Proceedings ACM Symposium on Principles of Distributed Computing, [NGF'T 901 Neuhold, E. J., Geller, J., Perl, Y., Turau, V.: A Theoretical Underlying Dual Model for Knowledge- Based Systems. Proceedings Systems ntegration, Morristown, New Jersey, [NS 881 Neuhold, E. J., Schrefl, M.: Dynamic Derivation of Personalized Views. Proceedings VLDB, [NW 821 Neuhold, E. J., Walter, B.: An Overview of the Architecture of the Distributed Data Base System "PO- REL". n Schneider, H. J. (Ed.): Distributed Data Bases. North-Holland, [Pu 881 Pu, C.: Superdatabases for Composition of Heterogeneous Databases, Proceedings EEE Data Engineering, [RGN 901 Rakow, T. C., Gu, J., Neuhold, E. J.: Serializability in Object-Oriented Database Systems. Proceedings EEE Data Engineering, [Ske 811 Skeen, D.: Nonblocking Commit Protocols. Proceedings ACM SGMOD, [TBC 871 Templeton, D., Brill, A., Chen, %;et al: Mermaid- A Front-end to Distributed Heterogeneous Database Systems. Proceedings of the EEE, Vol. 75, No. 5, [Wei 841 Weikum, G.: Architectural ssues of Transaction Management in Layered Systems. Proceedings VLDB, [Wei 861 Weikum, G.: A Theoretical Foundation of Multi- Level Concurrency Control. Proceedings PODS, [WHBM 901 Weikum, G., Hasse, C., Broessler, B., Muth, P.: Multi-Level Recovery. Proceedings PODS, [WV90] Wolski, A., Veijalainen, J.: 2PC Agent Method: Achieving Serializability in Presence of Failures in a Heterogeneous Multidatabase. Proceedings PAR- BASE,