2. Checking integrity constraints in multidatabase systems with nested transactions Anne Doucet, Stéphane Gançarski, Claudia León and Marta Rukoz Université P&M Curie, ParisUniversidad Central de Venezuela, Caracas

3. INTRODUCTION Database action 1, action 2, action n-1, action n......... All transactions must verify the ACID properties Flat Transactions User

4. action 1, action 2, action n-1, action n......... long lived transactions in new applications A lot of work could be lost because of aborted transactions New transaction models The best-known, implemented in commercial products: Nested Transactions (NT)

5. Nested Transactions (NT) [J. E. Moss]  Set of transactions that can be themselves NT TATA T A1 T A2 T A11 T A12 T A21 T A22 T A23 T A221 T A222 T A223 T A224 root child parent leaves optional obligatory  Only leaf sub-transactions can update objects.

6. Nested Transactions Behaviour Each sub-transaction of an NT is executed independently: it can decide either to commit or to abort at any time. If a sub-transaction decides to commit, this is not definitive, since the update of the system will only happen when the root transaction completes. If a sub-transaction decides to abort, its descendants will be aborted (modifications made by that sub-transaction are only known by the sub- transactions belonging to its sub-tree).

7. A sub-transaction may be: All the transactions in a NT (included the root) must follow this new definition of atomicity as well as the property of isolation. However, only the root of the NT has to preserve consistency and to be durable. u Obligatory: If it aborts, its parent must abort. Nested Transactions Behaviour u Optional:If it aborts, its parent can continue (partial abortion).  A NT may complete, while preserving consistency, although some of its sub-transactions have aborted.

8. Nested Transactions (NT) [J. E. Moss] TATA T A1 T A2 T A11 T A12 T A21 T A22 T A23 T A221 T A222 T A223 T A224 A NT can validate even if some of its subtransactions abort optional obligatory The NT have to satisfy all integrity constraints

9. Index Integrity Constraints Checking in Nested Transactions SystemsIntegrity Constraints Checking in Nested Transactions Systems Extension of Checking Strategies for Multidatabase SystemsExtension of Checking Strategies for Multidatabase Systems Conclusion

10. Integrity Constraints (IC) Checking : detection approach  ICs are:  defined in a global and declarative way.  checked at the end of the transaction  Compilation techniques are used to reduce the set of constraints to check:  a syntactic analysis of both constraints and transactions allows to determine the set of constraints that might be violated by a transaction.  the syntactic analysis determines the objects involved in a constraint and the objects touched by a transaction.

11. Constraints touched by a transaction  (C)  (T)  Property: A transaction T might violate a constraint C if : T 3 might violate C 1  (C 1 ) = { Person, Person.age }  (T 3 ) = { Person.age }  (C i ) : Set of objects involved in the constraint C i  (T j ) : Set of objects touched by transaction T j. (C 1 ) all p in Person, p.age  130 and p.age  T 3 () { for p in Person when (today = p.birthday) p.age := p.age + 1; }

12. Integrity Constraints Checking in Nested Transactions Systems  In our approach, constraints checking does not interfere with the NT execution control.  The leaves are flat transactions, so we can use the previous syntactic analysis  We check constraints as soon as possible and, in case of violation, abort as few as possible sub- transactions until reaching, whenever possible, the commit of the NT  The smallest common ancestor of the sub- transactions touching a constraint C i, SCA(C i ), is responsible for checking C i

13. Check(C 2 ) Optional transaction TATA T A1 T A2 T A11 T A12 T A22 C3C3 T A21 C4C4 T A211 C1C1 T A213 T A2131 C 1,C 2 T A2132 T A212 C 2,C 4 T A221 T A2221 C2C2 T A2222 T A222 Check(C 4 )Check(C 1 )Check(C 3 ) Integrity Constraints Checking in Nested Transactions Systems: Solution If C i is violated, we must abort sub- transactions touching C i and other sub- transactions which already used their results.

14. TATA T A1 T A2 T A11 T A12 T A22 C3C3 T A21 C4C4 T A211 C1C1 T A213 T A2131 C 1,C 2 T A2132 T A212 C 2,C 4 T A221 T A2221 C2C2 T A2222 T A222 Check(C 1 ) 1. T A211 sends "V" to T A21 2. T A2132 sends "V" to T A21 and T A2 3. T A21 runs Check(C 1 ) OK 4. C 1 is satisfied T A2132 T A211 Integrity Constraints Checking in Nested Transactions Systems: Example

15. Check(C 2 ) 5. T A2222 sends ‘‘V’’ to T A2 6. T A212 sends ‘‘V’’ to T A2 and T A 7. T A2 runs Check(C 2 )8. C 2 is violated KO TATA T A1 T A2 T A11 T A12 T A22 C3C3 T A21 C4C4 T A211 C1C1 T A213 T A2131 C 1,C 2 T A2132 T A212 C 2,C 4 T A221 T A2221 C2C2 T A2222 T A222 T A212 T A2222 T A211 T A2132 Integrity Constraints Checking in Nested Transactions Systems: Example

16. 8. C 2 is violated PropagateC 2 ) Propagate(C 2 ) 9. T A2 Propagate(C 2 ) to T A21 and T A22 10. T A21 abort => its subtree aborts Check(C 2 ) KO TATA T A1 T A2 T A11 T A12 T A22 C3C3 T A21 C4C4 T A211 C1C1 T A213 T A2131 C 1,C 2 T A2132 T A212 C 2,C 4 T A221 T A2221 C2C2 T A222 T A212 T A2222 T A211 T A2132 Integrity Constraints Checking in Nested Transactions Systems: Example

17. Check(C 2 ) KO Propagate(C 2 ) 11. T A21 is optional => T A2 can continue TATA T A1 T A2 T A11 T A12 T A22 C3C3 C4C4 T A221 T A2221 C2C2 T A222 T A2222 T A21 T A211 C1C1 T A213 T A2131 C 1,C 2 T A2132 T A212 C 2,C 4 Integrity Constraints Checking in Nested Transactions Systems: Example

18. Check(C 2 ) KO Propagate(C 2 ) 12. T A22 Propagate(C 2 ) à T A222 13. T A222 abort => its subtree aborts TATA T A1 T A2 T A11 T A12 T A22 C3C3 C4C4 T A221 T A2221 C2C2 T A222 T A2222 T A21 T A211 C1C1 T A213 T A2131 C 1,C 2 T A2132 T A212 C 2,C 4 Integrity Constraints Checking in Nested Transactions Systems: Example

19. Check(C 2 ) KO 14. T A222 is optional => T A22 can continue TATA T A1 T A2 T A11 T A12 T A22 C3C3 C4C4 T A221 T A2221 C2C2 T A222 T A2222 T A21 T A211 C1C1 T A213 T A2131 C 1,C 2 T A2132 T A212 C 2,C 4 Integrity Constraints Checking in Nested Transactions Systems: Example

20. 15. T A11 sends ‘‘V’’ to T A11 Check(C 3 ) OK 16. T A11 runs Check(C 3 )17. C 3 is satisfied18. T A12 sends ‘‘V’’ to T A 19. T A runs Check(C 4 ) Check(C 4 ) 20. C 4 is satisfied OK 21. T A can validate TATA T A1 T A2 T A11 T A12 T A22 C3C3 C4C4 T A221 T A2221 C2C2 T A222 T A2222 T A21 T A211 C1C1 T A213 T A2131 C 1,C 2 T A2132 T A212 C 2,C 4 T A11 T A12 Integrity Constraints Checking in Nested Transactions Systems: Example

21. Integrity Constraints Checking in Multi-DB with Nested Transactions.. Global Nested Transactions local Manager DB 1 DB 2 local Manager DB n local Manager Global Schema Global Transaction Manager (GTM) Multidatabase DBMS

22. T T1T1 T 111 T 112 T 21 T 22 T 221 T 222 Site 3 T 1111 T 1112 Site 2 T 12 T 11 Site 1 Site k Only leaf sub-transactions can update objects. Each leaf is totally executed on a single site. The assignment of the sub-transactions of a NT to the different sites is induced by the localisation of the objects in the network Distributed Nested Transaction (DNT) T2T2

23. T T1T1 T2T2 T 111 T 112 T 21 T 22 T 221 T 222 Site 3 T 1111 T 1112 Site 2 T 12 T 11 Site 1 Site k C1C1 C2C2 C3C3 SCA(C 1 ) SCA(C 2 ) SCA(C 3 ) SCA(C i ) is responsible for checking C i Check(C i ) is itself a DNT Problem: Where to execute Check(C i ) to minimise the transfer of data among sites? It depends on the constraint !! Integrity Constraints Checking for DNT

24. Site 3 Site 2 Site 1 T T1T1 T 111 T 112 T 21 T 22 T 221 T 222 T 1111 T 1112 T 12 T 11 T2T2 Site k C1C1 C3C3 C2C2 SCA(C 1 ) SCA(C 2 ) SCA(C 3 ) C 2  Local constraint C 1,C 3  Global constraints C 11  C 12 ...  C 1n C 11  C 12 ...  C 1n where C ik is local to site S k Defined by using any predicate type, quantifier and connector. Locally checkableNon locally checkable Integrity Constraints Checking for DNT Check(C 1 ) Check(C 13 ) Check(C 12 )Check(C 11 ) Check(C 2 ) Conjunctive Global Constraint

25. Global IC non locally checkable Conjunctive Global Constraint  (o 1  CL 1, o 2  CL 2,..., o n  CL n ) F 1 (X 1 )  F2(X 2 )...  F j (X j )  F j+1 (X j+1 )  F j+2 (X j+2 ) ...  F m (X m ) WhereF i is any predicate X i is any subset of {o 1, o 2,..., o n } This type of constraints appears when chains of relationships exist between objects of different local databases

26. Site 2 Site 1 colormark Car Class attributes owner reference Person age  ( v  Car, p  Person), ( mark(v) = Ferrari  Owner(v) = p)  age(p)  33 Conjunctive Global Constraint : Example Principles of Checking Strategy:  The smallest common ancestor is responsible for the control [DGLR99].  For each site, and for each constraint, a locally satisfied predicate guarantee the global constraint [GW93].  Decomposition of universally quantified global constraints into a conjunction of inter-sites predicates [Grufman97].

27. Site 2 Site 1 colormark Car Class attributes Owner reference Person age  ( v  Car, p  Person), ( mark(v) = Ferrari  Owner(v) = p)  age(p)  33 Conjunctive Global Constraint : Example T T touches the age of Person p 1. If age(p)  33 : C ok 2. Else : C ???? 2.1Intersite 2 = {p / age(p) < 33} 2.2send Intersite 2 to Site 1 Site 2 2.3 If  ( v  Car, p  Intersite 2 ) (mark(v) = Ferrari  Owner(v)  p) : C ok 2.4 Else : C ko Site 1

28.  DNT are taken into account  We propose a classification of strategies depending of the constraint’s nature and on the structure of the transactions  For non locally checkable constraints we combine our approach ( DGLR00 ) with the works of Gupta and Widom ( GW93 ) and Grufman et al. (Grufman97) Conclusion

29. Future Work  Proof and implementation of our solution.  Adaptation of our approach to other transaction models: multi-level transactions, sagas, open nested transactions, etc.  Optimisation via abortion of fewer sub- transactions using the concurrency control information, that shows if a sub-transaction influences other sub-transactions.

31. Conjunctive Global Constraint : Checking strategy Some leaves transactions touch C on Site 1 and on Site 2 Check(C)  Site SCA (C) Check(CMJ1) ; Check(PL1)Check(PL2) Intersite 1 Check(CMJ2) ; Check(CL2)Check(CL1) Intersite 2 Site 2 Site 1 Site 2 TT ’