Serializability of Nested Transactions in Multidatabases ?
Ugur Halici1 , Budak Arpinar2 and Asuman Dogac2 Software Research and Development Center Engineering, 2 Dept. of Computer Engineering Middle East Technical University (METU), 06531 Ankara Turkiye
[email protected], fasuman,
[email protected] 1 Dept. of Electrical
Abstract.
The correctness of nested transactions for multidatabases differs from that of at transactions in that, for nested transactions the execution order of siblings at each related site should also be consistent. In this paper we rst propose a simple but powerful theory for the serializability of nested transactions in multidatabases and then a technique called Nested Tickets Method for Nested Transactions (NTNT). The NTNT technique provides correctness of nested transactions in multidatabases without violating the local autonomy of the participating DBMSs. The algorithm is fully distributed, in other words there is no central scheduler. The correctness of the NTNT technique is proved by using the developed theory.
1 Introduction and Related Work A multidatabase system (MDBS) is a software that allows global applications accessing data located in multiple heterogeneous, autonomous DBMSs by providing a single database illusion. A multidatabase environment supports two types of transactions: local transactions submitted directly to a single Local DBMS (LDBMS), and executed outside the control of MDBS and global transactions that are channeled through the MDBS interface and executed under the MDBS control. The objectives of a multidatabase transaction management are to avoid inconsistent retrievals and to preserve the global consistency in the presence of updates. Transaction management has always been one of the most important parts of a DBMS GR 93]. The research on transaction management for centralized DBMSs is rst extended to distributed DBMSs BHG 87, HD 89, HD 91] and then to multidatabases. The transaction management for at transactions in multidatabases have received considerable attention in recent years and correctness criteria have been de ned ZE 93] and several concurrency control techniques have been suggested BGS 92, ZE 93, GRS 94]. In GRS 94] ?
This work is partially being supported by the Turkish State Planning Organization, Project Number: AFP-03-12DPT.95K120500, by the Scientic and Technical Research Council of Turkey, Project Number: EEEAG-Yazilim5, by Motorola (USA) and by Sevgi Holding (Turkey)
a ticket method is suggested to enforce serializability of global transactions in a MDBS environment. However it has been observed that nested transactions are more suitable to distributed environments since they provide more general control structures and support reliable and distributed computing more eectively. Nested transactions M 85] facilitate the control of complex persistent applications by enabling both ne-tuning of the scope of rollback and safe intratransaction parallelism. As a result nested transactions have become integral parts of some important standards, e.g. OMG's Common Object Services Speci cation (COSS). OMG's transaction service speci cation supports nested transactions along with at transactions in a distributed heterogeneous environment based on the CORBA architecture OMG 94]. Yet, to the best of our knowledge there is no technique suggested for the correctness of nested transactions in multidatabases, although some multidatabase projects have decided to use nested transaction model in their implementations HFBK 94, DDK 96]. Principles and realization strategies of multilevel transaction management is described in W 91]. A multi-level transaction approach to federated DBMS transaction management is discussed in SWS 91]. DOM Transaction Model BOH 92] for multidatabases allows closed nested and open nested transactions. InterBase Transaction Model ELLR 90] is based on nested transaction model and allows a combination of both compensatable and non-compensatable subtransactions. However the correctness theory has not yet been developed for the models mentioned above. In this paper we have developed a simple, neat and powerful theory for the serializability of nested transactions in multidatabases. Note that the theory provided in BBG 89] for nested transactions could have been generalized to multidatabases. However the theory developed in BBG 89] is very general in the sense that it takes semantics of transactions into account by allowing compatible transactions. Thus to prove the correctness of a concurrency control technique, commutativity and pruning concepts are used. We are able to develop a simpler theory, provided in Section 3, by not taking the semantics of transactions into account. We then present a technique called Nested Tickets Method for Nested Transactions (NTNT) that provides for the correct execution of nested transactions in multidatabases. It should be noted that the concurrency control techniques developed for at multidatabase transactions do not provide for the correctness of nested transactions in multidatabases because for nested transactions a consistent order of global transactions is not enough the execution order of siblings at all levels must also be consistent at all sites. The main idea of NTNT technique is to give tickets to global transactions at all levels, that is, both the parent and the child transactions obtain tickets. Then each global (sub)transaction is forced into conict with its siblings through its parent's ticket at all related sites. The recursive nature of the algorithm makes it possible to handle the correctness of dierent transaction levels smoothly. NTNT technique also produces correct executions for at transactions, at transactions being a special case of nested transactions.
NTNT technique is fully distributed and does not violate the autonomy of participating LDBMSs. A transaction manager using the NTNT technique is implemented within the scope of the METU Interoperable DBMS (MIND) project DDK 96, DEO 96]. MIND is based on OMG's object management architecture and is developed on top of a CORBA OMG 91] compliant ORB, namely, DEC's Object Broker. A generic database object is de ned through CORBA IDL and an implementation is provided for each of the participating DBMSs (namely, Oracle72, Sybase3 , Adabas D4 and MOOD (METU Object-Oriented DBMS) DAO 95]). Among these DBMSs Sybase and Adabas D support nested transactions. Therefore the restrictions of a global transaction to Sybase and Adabas D servers can be nested transactions, the others are at transactions. The paper is organized as follows: In Section 2 nested transaction models for centralized and multidatabase systems are given. Section 3 introduces a serializability theory for nested transactions in multidatabases. In Section 4, NTNT technique and its correctness proof are presented. We conclude with Section 5.
2 Nested Transactions A nested transaction is a tree of transactions, the subtrees of which are either nested or at transactions. The transaction at the root of the tree is called the top-level transaction. The others are called subtransactions. A transaction's predecessor in the tree is called a parent and subtransaction at the next lower level is called a child. The ancestors of a transaction are the parent of the subtransaction and recursively the parents of its ancestors. The descendants of a transaction are the children of the transaction and recursively the children of its descendants. The children of one parent are called siblings. We use the term (sub)transaction to refer to both top-level transaction and subtransactions.
2.1 A Nested Transaction Model In the following we summarize a nested transaction model CR 91] that we use in our work. Let 0 be the top-level transaction, p be a root or a subtransaction, c be a subtransaction of p , and a be the ancestors of c . i. Abort Rule: All the children c must be aborted if the parent transaction p aborts. A child transaction can abort independently without causing the abortion of its ancestors. ii. Commit Rule: The parent transaction p cannot commit until all its children c commit or abort. The child transaction will nally commit only if it has committed and all its ancestors have nally committed. iii. Visibility Rule: The child transactions c can view the partial results of their ancestors a , plus any results from committed detached transactions. Also they can view the partial results of their committed siblings due to following t
t
t
t
t
t
t
t
t
t
t
t
2 3 4
Oracle7 is a trademark of Oracle Corp. Sybase is a trademark of Sybase Corp. Adabas D is a trademark of Software AG Corp.
delegation rule.
iv. Delegation Rule: At commit, child transaction c delegates its objects to t
parent transaction p . So all changes done by a child transaction become visible to the parent transaction upon the child transaction's commit. The eects of delegation can be found in CR 91]. v. Conict Rule Between A Child Transaction and Its Ancestors: Consider a child transaction c and its ancestors a and conicting operations and : a can not invoke after c invokes . 2 It should be noted that rule v. prevents parent/child parallelism. t
t
q
t
q
t
t
p
p
2.2 A Nested Transaction Model for Multidatabases In distributed systems such as multidatabases, nested transaction model provides more general control structures to support reliable and distributed computing more eectively HR 93]. A nested transaction submitted to a multidatabase may have to be executed in several LDBMSs if the related data is scattered across a number of sites. Operations submitted by (sub)transactions are executed by LDBMSs' Data Managers (DM) and they are called as DM operations. If a (sub)transaction in the hierarchy has a DM operation in a LDBMS, the operation is dispatched to the related site. If a LDBMS does not support nested transactions, their eect with respect to hierarchical domains of recovery can be simulated by using savepoints GR 93]. Since each (sub)transaction of a nested transaction is failure-atomic, restrictions of a (sub)transaction to sites must be executed as an atomic unit. So, atomicity rule is de ned for nested multidatabase transactions as follows: Let be a (sub)transaction and k be the restriction of at sites = 1 2 . i. Atomicity Rule: All the restrictions of a (sub)transaction at sites = 12 should be aborted if aborts. t
t
t
k
::: n
t
::: n
k
t
3 A Serializability Theory for Nested Transactions in Multidatabases Before presenting the serializability theory of nested transactions in multidatabases, we provide an intuitive explanation. It is possible to view a nested transaction as a tree, where the leaf nodes contain the DM operations and intermediate nodes represent the subtransactions. Note that this tree is not necessarily balanced. When a nested transaction is executed, the (sub)transactions that conict on the same data item must be ordered in such a way that the order of their conicting DM operations are preserved. Another important point is that when two subtransactions are ordered, this imposes an order between their parents. To be able to express these concepts formally we de ne an ordered hierarchy where the ordering imposed by the leaf nodes are delegated to the upper nodes in the hierarchy. With this ordered hierarchy de nition it is possible to formally model an ordering within a
t1
t 11
t1
t11
t111
t
t12
t112
t 121
t 122
t 112
111
t 1111
t 1112
t 1121
t 12
t 1122
t 1123
a. Subhierarchy
H11 :
b. Restriction
H11 :
t 121
t 122
1
c. Hierarchy Portion P 1 : 11
(a)
(b)
Fig. 1. (a) Illustration of delegation axiom, (b) Subhierarchy, restriction, and hierarchy portion
tree. Furthermore by assuming an imaginary root transaction for all submitted transactions it is possible to model an execution history of nested transactions through the ordered hierarchy de nition. In order to extend the theory to distributed DBMSs, we de ne restriction of a hierarchy to represent the executions at dierent sites. And to extend the theory further to multidatabases, where there is no global control on local transactions, we de ne global portion and local portions of an execution. Denition 1. An ordered hierarchy (or shortly a hierarchy) is a tuple = (! ) where is a set of nodes, is a tree on , and ! is a nonreexive and antisymmetric relation on satisfying the following axioms for any 2 a. parent-child order5 : ( )! b. transitivity: if ! and ! then ! c. delegation: if ! and i. if ( ) 62 ( ) then ! () ii. if ( ) 62 ( ) then ( ) ! .2 In fact the relation de ned is an ordering relation with further restrictions imposed by De nition 1.a and 1.c. The closure obtained by by applying the axioms of the hierarchy de nition repeatedly is denoted by . Figure 1.(a) presents an example to clarify the delegation axiom. Given an H
O T
O
T
O
O
a b
parent a
a
a
parent b
parent a
5
b
b
O
a
c
a
c
b
ancestors a
ancestors b
a
parent b
parent a
b
Note that ordered hierarchy denition takes only sibling parallelism into consideration assuming the conict rule given in Section 2.1.v. Therefore we have chosen parent's preorder priority in Denition 1.a.
ordering 111 ! 121 , 111 and 12 (which is ( 121 )) are ordered as 111 ! ( 111 )) are ordered 12 (from De nition 1.c.i). Also 121 and 11 (which is as 11 ! 121 (from De nition 1.c.ii). Yet although 121 and 122 are ordered as ( 122 )) is also one of the ( 121 ), 121 ! 122 , since 12 (which is the order is not delegated upwards. Finally, 11 and 12 are ordered as 11 ! 12 (from De nition 1.c.i and ordering 11 ! 121 ). Denition 2. Let = (! ) be a hierarchy, and i be a complete subtree of rooted at the node i 2 , and let ik be a part of i such that ik is also a tree rooted at the node i but ( ik ) ( i). A restriction H is the k k k k k tuple i = (!i i i ) where i is the set of nodes related to ik and !ki is the restriction of the order ! to ik . If ik = i then the restriction is denoted as i = (!i i i ) and called as subhierarchy. A hierarchy portion P k k of on restriction ik is the hierarchy tuple ik = (!Pk i i i ) satisfying Pk k !i !i . If k i is kitself, then restriction and portion related to part k are k k ) and k = (!Pk k k ) respectively.2 denoted as = (! Figure 1.(b) shows: a subhierarchy 11 rooted at 11 with !11 = f 1111 ! 1 with !1 = 1112 1112 ! 1121 1121 ! 1122 111 ! 112 g , a restriction 11 11 1 with f 1112 ! 1121 1121 ! 1122 111 ! 112 g , and a hierarchy portion 11 !P111= f 1112 ! 1121 111 ! 112g. Note that !P111!111!11 and ( 111 ) ( 11). In Figure 1.(b) transitive edges and edges from parent to child are not shown for the sake of simplicity. Proposition 1. Given hierarchy = (! ) then a restriction ik = (!ki k k i i ) is also a hierarchy since it satis es De nition 1.2 In the following de nition, a partial order represents an irreexive, antisymmetric, and transitive relation. Denition 3. A hierarchy = (! ) is said to be partially (totally) ordered i ! is a partial (total) order on .2 Denition 4. A subhierarchy i = (!i i i) of a hierarchy = (! ) is said to be isolated in i for any im , in 2 i , l 2 ; i ; ( i ), the following holds: ( im ! l ! in ) and either l ! im or im ! l .2 Denition 5. A subhierarchy i = (!i i i) of a hierarchy = (! ) is said to be hierarchically isolated in i every subhierarchy ij (including i itself) of i is isolated in .2 Denition 6. A hierarchy = (! ) said to be serial if itself is hierarchically isolated and ! is a total order.2 Denition 7. A hierarchy = (! ) is said to be serializable if there exists a serial hierarchy + = (!+ ), such that !!+ .2 Theorem 1. A hierarchy = (! ) is serializable i ! is a partial order. Proof: (if) Consider the preorder traversal of where the siblings are traversed in consistency with the order !. If the siblings are not ordered by ! then their traversal order is immaterial. Since ! is a partial order and since ! is closed under delegation axiom, such a traversal exists. Let !+ be the total order determined by such a preorder traversal. Obviously !!+ and + = (!+ ) is serial. Therefore = (! ) is serializable by de nition. (only if) Assume = (! ) is serializable and ! is not a partial order t
t
t
t
t
parent t
t
t
t
t
t
t
t
t
ancestors t
t
H
t
t
T
T
T
leaves T
O T
t
t
O
t
T
k i
leaves T
O
T
O
H
t
O T
T
H
t
parent t
t
T
T
k i
O T
H
H
T
P
O T
T
T
H
O T
P
O T
H
t
t
parent t
t
t
t
t
t
t
t
t
t
t
t
t
t
t
t
t
H
t
P
t
leaves T
leaves T
H
O T
H
O T
H
O T
O
H
O T
H
t
not t
t
t
t
H
H
O
O T
t
O
t
t
O
t
H
t
H
H
H
O T
ancestors t
O T
H
H
H
O T
H
H
O T
H
O T
H
O T
T
H
H
O T
H
O T
O T
(Note that our partial order relation is irreexive, antisymmetric and transitive). Since ! is transitive by de nition of a hierarchy, there should be ! for some 2 . However, this in turn implies that there is no total order satisfying !!+, which means is not serializable.2 a
a
a
O
H
t
1
t 11
t 12
t 111
t 121
t 112
t 1111
t 1121
t 122
Fig. 2. An unserializable hierarchy
As an example to an unserializable hierarchy consider Figure 2. An initial order is given as f 121 ! 1111 1121 ! 122 g !. From the de nition of ordered hierarchy, ! also contains the following set obtained by applying the delegation axiom of De nition 1.c repeatedly: f 1121 ! 12 112 ! 12 11 ! 12 12 ! 1111 12 ! 111 12 ! 11 g. ! is not a partial order because of 12 ! 11 and 11 ! 12 and hence the hierarchy in Figure 2 is not serializable. Denition 8. A nested transaction is a tree on = dm tr where dm are the nodes representing the DM operations and tr are the nodes corresponding the abstract operations representing (sub)transactions, such that f ( )g = dm and = ( ) is the node representing the abstract operation corresponding to and any subtree i rooted at i 2 f ( ); ( )g is a subtransaction de ned recursively.2 We assume an imaginary top-level transaction such that any transaction submitted by the users is a subtransaction of it. Thus it is possible to model the execution history of nested transactions as an ordered hierarchy. Denition 9. An execution history is an ordered hierarchy = (! ) where is a transaction on and != (!dm !ep ) where !dm is the ordering requirements on the leaf nodes due to execution order of conicting DM operations, !ep is the ordering requirement due to execution policy6 . A t
t
t
t
t
t
t
t
t
t
t
t
t
t
t
t
t
t
t
t
T
O
O
O
O
O
leaves T
O
t
root T
T
T
t
child t
H
T
6
leaves T
O T
O
If there are additional ordering requirements due to transactions ! can be written as != (!dm !ep !ts ) where !ts is the transaction specic ordering requirements. However it is easier here to assume any execution policy to cover such requirements, that is !ts !ep .
subhierarchy of an execution is called a subexecution and a hierarchy portion of it is called an execution portion.2 Two DM operations are in conict if one of them is a write operation, they operate on the same data item and they belong to dierent parents in the transaction tree. Note that in the transaction tree, the parent of a DM operation is the (sub)transaction itself that issued the DM operation. We take the serializability of an ordered hierarchy as the correctness criterion of executions. Therefore as a consequence of Theorem 1 an execution history = (! ) is correct i ! is a partial order. At this point it should be noted that to provide the correctness of executions it is sucient to nd a total order consistent with the order of conicting DM operations. In other words !dm is the order to be preserved. Yet, a concurrency control technique while trying to guarantee the consistent order of DM operations may introduce a more restrictive ordering. We denote the ordering that stems from the execution policy as !ep . As an example, in a technique that allows only serial executions, !ep itself is a total order. In centralized databases only a single site contributes to the execution and the serializability of the execution can be checked easily. In distributed databases there are several sites contributing to the execution. Denition 10. A distributed execution = (! ) is an execution hisk ) where k is the set of DM operations on tory such that dm = k ( dm dm data items stored at site , for = 1 . The execution of at site is the k .2 restriction k = (!k k k ) such that ( k ) = dm k l Notice that dm \ dm = when 6= , however this is not true in general for trk and trl , since trk \ trl gives root nodes corresponding to subtransaction trees having DM operations at both sites. = (! ) with restrictions k = (!k k k ) at site , for = 1 , satis es = k ( k ), = k ( k ), and !=(k !k ) . ! contains the order enforced by the distributed execution policy, !dep in addition to k !kdm on the other hand !k contains also !kdep . In distributed DBMSs, the concurrency control information related to hierarchy restrictions are completely available and can be used to decide on the serializability of the execution. In distributed DBMSs the restriction k = (!k k k ) of at site is known. However, in multidatabases, the complete information about is not available. A local scheduler at site knows only the local execution portion k = (!Lk k k ) where !Lk !k and does not have the complete information on the restriction k = (!k k k ). Furthermore a global scheduler in multidatabases have knowledge only about global execution portion, = (!G G G) while a distributed DBMS scheduler has the complete information about = (! ). Denition 11. On a multidatabase having sites = 1 , a multisite execution = (! ) is an execution history such that = G (Lkk Lk ),G G = k Gk , and = G (k Lk), G = k Gk and != ((k ! ) ! ) , H
O T
O
O
k
H
O
O
H
k
O
leaves T
O
k
H
l
H
O
k
O
O T
O
O T
:: n
O T
O
O
H
O
T
O T
k
k
H
H
:: n
T
O T
k
H
k
L
O T
H
O T
G
O
T
H
O T k
H
O
:: n
O T
O
O
O
O
T
T
T
T
T
! ! ! ! ! ! ! ! ! ! ! !
k = ( k Ok T k ) at site k , for k = 1 :: n where H has restrictions H k Gk Lk k O = O O and T = T Gk T Lk with a local execution portion Lk = ( Lk k k Lk k , Lk = ( Lk Lk ) where Lk is the ordering enforced O T ), dm lep lep by local execution policy, g = ( g OG T G ) to T G with a global execution portion H has restriction H G G G G G = ( O T ), = (( k Gk ) gep ) where gep is the ordering due dm G g to global execution policy, , k = ( Gk OGk T Gk ) at sites k = 1 :: n, Gk k, G has restriction G Gk G and Gk Lk (but not necessarily Gk Lk or Lk Gk ).2 dm dm
! ! !
!
! !
L1
T G1
T1
dm
!
!
!
! ! ! !
! !
gep
L2
T G2
dm
T1
dm
dm
Site 1
Site 2
Fig. 3. A Multisite execution H
Figure 3 depicts a multisite execution where the edges due to axioms of De nition 1 are not demonstrated for the sake of simplicity. Figure 4.(a) shows local execution portions 1 and 2 of at site 1 and site 2 respectively. Note that local scheduler at site 1 does not have the complete knowledge of !1 which contains orderings that come from local scheduler at site 2 such as 2G ! 1G. This is symmetrically true for the local scheduler at site 2. Also ordering due to global execution policy is hidden from the local schedulers. In Figure 4.(a), these orderings which are not included in !L1 and !L2 are depicted as dotted lines and the delegated orderings are displayed as dashed lines. In Figure 4.(b), the global execution portion of is given. !G does not contain orderings coming from local schedulers due to conicting DM operations with local transactions at those sites and these orderings are also depicted as dotted lines. One of the necessary condition for serializability of is that (k !k ) should not introduce any cycles, which is not satis ed in the example shown in Figure 3 and Figure 4. Denition 12. A multisite execution is said to be EGOL (enforcing global order locally on siblings) i !Gk implies !Lk whenever ( )= ( ), and 2 G , and 2 k for any 2 .2 Denition 13. A multisite execution is said to be ELOT (enforcing local ordering transparency for siblings) i !Lk implies !Gk whenever ( )= ( ), and 2 G , and 2 k for any 2 .2 If an execution is EGOL and ELOT, then the order of the siblings are conH
L
L
H
T
G
T
H
H
a
parent b
a b
O
parent a
parent b
b
a b
a
O
a
a b
O
b
a b
a b
b
O
parent a
O
a
a b
b
O
gep
L1
TG 1
T1
dm
G gep
T G2
L2
T2
dm
dm
T G1
TG 1
T1
gep
T G2
dm
Site 1
Site 2 (a)
(b)
Fig. 4. (a) Local execution portions L1 and L2 of H at site 1 and site 2, (b) Global execution portion G of H
sistent at each site as shown in the following Lemma. Lemma 1. If a multisite execution = (! ) is EGOL and ELOT then !Lk l implies !Llk for any site whenever ( )= ( ), and 2 andLk 2 for any Gk 2 . Proof: ! implies ! by ELOT property which inturn implies !G since l k = (!Gk l Gk GlGk) isGltheGlrestriction of at sites . !Gl since 2 and since = (! ) is the restriction of at sites . Furthermore, since the restriction is EGOL, !Gl implies !Ll .2 Theorem 2. Let = (! ) be a multisite EGOL and ELOT execution having serializable local execution portions k = (!Lk k k ) at site for = 1 . Then is serializable i the global portion = (!G G G) is serializable. Proof: (if) Due to EGOL and ELOT properties of and Lemma 1, and due to serializability of k for = 1 and serializability of all the orderings in !G and !Lk , = 1 are consistent for any siblings . Therefore a preorder traversal !+ (total order) of exists for any siblings and such that !+ is consistent with the following: H
a
a b
b
a
O
a b
a
a
b
O
a b
b
b
a
G
a b
parent a
T
G
G
O
:: n
a
b
G
b
a
l
b
O T
L
k
k
T
a
H
parent b
O
b
O
O
O T
k l
O T
H
G
k
O
T
H
L
k
k
:: n
G
:: n
a b
T
a
b
1. If 2 G and !G then is traversed before , 2. If 2 k and !Lk for any then is traversed before , 3. Otherwise the ordering of and is immaterial a b
O
a b
O
a
a
b
a
b
b
k
a
b
and this preorder traversal satis es !!+ . Since !+ is a total order consistent with !, is serializable. a
b
H
(only if) If is serializable then ! is a partial order by Theorem 1. Since !G! by de nition this in turn implies !G is a partial order. Therefore G H
is serializable by Theorem 1.2
H
4 Nested Tickets Method for Nested Transactions In this section, a technique for global concurrency control of nested transactions in multidatabases, called Nested Tickets Method for Nested Transactions (NTNT) is presented. NTNT ensures global serializability of nested multidatabase transactions without violating autonomy of LDBMSs. It is assumed that LDBMSs' schedulers guarantee local serializability of nested transactions. We present the NTNT technique by referring to the pseudocode of the algorithm. To be able to provide a neat recursive algorithm, we imagine all the global transactions to be children of a virtual transaction called OMNI. When OMNI transaction starts executing, it creates a siteTicket(OMNI) at each site whose default value is 0. Then we imagine that OMNI transaction executes forever. Since it is an imaginary transaction, it does not need to commit nally to make the updates of its children persistent. GlobalBegin( iG ) assigns a globally unique and monotonically increasing ticket number denoted as ( iG) to all transactions denoted by iG when they are initiated, that is, both the parent and the child transactions at all levels obtain a ticket. A Ticket Server object in MIND provides tickets and guarantees that any new subtransaction obtains a ticket whose value is greater than any of the previously assigned ticket numbers. Since any child is submitted after its parent, this automatically provides that any child has a ticket number greater than its parent's ticket. When the rst DM read or DM write operation of a subtransaction G G i is to be executed at a local site, LocalBegin( i , k) is executed which starts all ancestors of the subtransaction if they are not initiated at this site yet. Next, each child transaction reads the local ticket created by its parent at this site (this ticket is created for the children of ( iG), i.e. ( iG)), and checks if its own ticket value is greater than the stored ticket value in the ticket for ( iG) at this site. If it is not, the transaction iG is aborted at all related sites and resubmitted to MIND using the algorithms given in GlobalAbort( iG ) and GlobalRestart( iG). Otherwise, iG sets the local ticket created by its parent to its own ticket value ( ( iG)) and creates a site ticket, ( iG) with default value 0 for its possible future children. As a result, all siblings of a subtransaction accessing to some site are forced into conict through a ticket item created by the parent of these siblings at site . The pseudocode of the algorithm to check ticket values is presented in LocalCheckTicket( iG , k). This mechanism makes the execution order of all siblings of a subtransaction to be consistent at all related sites since the execution is EGOL and ELOT by the use of tickets. In other words, the consistency of serialization order of the siblings are provided by guaranteeing them to be serialized in the order of their ticket numbers. If a transaction is validated using the LocalCheckTicket( iG , k) algorithm then its read and write operations on any item are submitted to related LDBMS by LocalWrite(x), LocalRead(x) algorithms and committed by GlobalCommit( iG ). GlobalCommit( iG ) is executed after all children of iG commit or abort due to Commit Rule in Section 2.1.ii. GlobalCommit( iG ) coordinates the 2PC protocol and if all LDBMSs replied Ready then commits this subtransaction. T
TN T
T
T
T
parent T
siblings T
siblings T
T
T
T
T
TN T
siteT icket T
k
k
T
T
x
T
T
T
T
The NTNT Algorithm:
GlobalBegin(TiG ): Get global ticket for TiG so that TN(TiG ):=lastTicketNo+1 lastTicketNo:=TN(TiG ) 2 LocalBegin(TiG, k): If parent(TiG , k) has not started at site k yet then LocalBegin(parent(TiG), k) Forward begin operation for TiG as child of parent(TiG ) to Local Transaction Manager (LTM) at site k else Forward begin operation for TiG as child of parent(TiG ) to LTM at site k LocalCheckTicket(TiG, k) If check FAILs then GlobalRestart(TiG ) 2 LocalCheckTicket(TiG, k): If TiG is not OMNI then If siteTicket(parent(TiG )) > TN(TiG ) then FAIL else siteTicket(parent(TiG )):=TN(TiG ) create(siteTicket(TiG )) at site k with default value 0 2 LocalWrite(x), LocalRead(x): If the site(x) is being visited for the rst time by TiG then LocalBegin(TiG, k) Forward the read/write operation to Local Data Manager on behalf of TiG 2 GlobalAbort(TiG ): for each related site send LocalAbort(TiG ) message to LTM at site k 2 GlobalRestart(TiG ): GlobalAbort(TiG ) GlobalBegin(TiG ) 2 GlobalCommit(TiG ): wait until all children(TiG ) commit or abort for each related site k send PrepareToCommit(TiG) message to LTM at site k If all LTMs have replied Ready for each related site k send Commit(TiG ) message to LTM at site k If any site fails to PrepareToCommit then GlobalAbort(TiG ) 2
An Example: In the following, an example is provided to clarify the NTNT
technique. Assume a multidatabase system with two LDBMSs at sites 1 and 2. User transactions can be arbitrarily nested and each (sub)transaction can issue read and write operations denoted as ( ) and ( ) respectively. Figure 5 depicts the execution of two nested multidatabase transactions 1G and 2G, and a local transaction 1L2. Global transaction 1G has two subtransactions 11G and 12G , and 2G has one subtransaction 21G . At site 1, rst 1G writes , then 11G writes , and then 21G reads . Therefore, 1G and 21G directly conict at site 1 and the serialization order of the transactions is f 1G ! 21G g !1 . r a
w a
T
T
T
T
a
T
T
T
T
a
T
T
a
T
T
T
T
T
OMNI
T G2
T 1G
G T 11
w1(a)
w11(a)
TG 21
G T 12
r 21(b)
r 21(a)
L2
T1
wL1(b)
Site 1
wL1(c)
w12(c)
Site 2
Fig. 5. A Schedule of Nested Multidatabase Transactions Using the delegation axiom in De nition 1.c the serialization order of 1G and G 1 G G G G 2 at site 1 is f 1 ! 2 g ! . At site 2, 21 reads and later 12 writes G G . Therefore, there is no direct conict between 21 and 12 at site 2. However, a local transaction 1L2 writes and , and thus 21G and 12G conict indirectly at site 2. Therefore the serialization order is f 21G ! 1L2 ! 12G g !2 at site 2. Using the delegation axiom the serialization order of 1G and 2G at site 2 is f 2G ! 1GGg !2.GBecause of the local autonomy, the indirect conict between siblings 12 and 21 at site 2 cannot be detected at the global level without a technique like NTNT. Although local schedules for nested transactions are serializable, the complete schedule is not serializable because the local schedules at sites 1 and 2 are not consistent with a total order f!1 !2 g ! de ned on transactions 1G and 2G. NTNT technique works for this example as follows: Assume the tickets obtained from the ticket server to be as follow: ( ) = 0, ( 1G) = 1, G G G G ( 2 ) = 2, ( 11) = 3, ( 21) = 4, ( 12) = 5 and let ( ) = 0 at each site. Execution at site 1: G ( ( 1G)) = ( )= 0 1 is accepted since G ( 1 ) = 1 and ( ) is set to 1 and ( 1G) is created with default value 0. Thus 1 ( ) is executed. Since ( ( 11G)) = G G G 0 ( 11) = 3, ( ( 11)) is set to 3 and ( 11) = 0 is created and 11 ( ) is executed. Similarly ( ( 2G)) = ( )=1 ( 2G) = 2, 2G is accepted and ( ) becomes G 2 and ( 2 ) is created with default value 0. 21 ( ) is executed because ( ( 21G )) = 0 ( 21G ) = 4 and ( ( 21G )) is set G to 4 and ( 21) is created with default value 0. T
b
T
T
T
T c
T
T
b
c
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T
T N OM N I
TN T
TN T
TN T
TN T
TN T
siteT icket
OM N I
T
siteT icket parent T
TN T
siteT icket OM N I w
< TN T
a
< TN T
siteT icket parent T
siteT icket T
siteT icket parent T
siteT icket T
siteT icket T
siteT icket parent T
T
siteT icket
siteT icket OM N I r
< TN T
