1. Multidatabase Transaction Management COP5711

2. Multidatabase Transaction Management Outline Review - Transaction Processing Multidatabase Transaction Management Issues Global Serialization Techniques Global Atomicity and Recovery Problems Global Deadlock Problem

3. Multidatabase Transaction Management ACID Property Atomicity: A transaction is either performed in its entirety or not performed at all Consistency: A correct execution of the transaction must take the database from one consistent state to another Isolation: A transaction should not make its updates visible to other transaction until it is committed Durability: Once a transaction changes the database and changes are committed, these changes must never be lost because of subsequent failure

4. Multidatabase Transaction Management Transaction Histories (Schedules) A history lists the order in which actions of a set of transactions were successfully completed. r 1 (a) c 1 w 3 (a) r 2 (b) c 2 w 3 (b) c 3 A history preserves the order of the actions in each of the transactions. An initial state and a history completely define the system ’ s behavior.

5. Multidatabase Transaction Management Serial History The simplest histories first run all the actions of one transaction, then run all the actions of another to completion, and so on. r 1 (a) c 1 w 3 (a) w 3 (b) c 3 r 2 (b) c 2 Such one-transaction-at-a-time histories are called serial histories. serial histories have no concurrency-induced inconsistency and no transaction sees dirty data (  They are correct !)

6. Multidatabase Transaction Management Locking constraints the set of allowed histories.  Histories are not constructed, they are a byproduct of the system behavior. Histories that obey the locking constraints are called Legal. Legal Histories

7. Multidatabase Transaction Management Legal Histories - Examples Histories are not constructed, they are a byproduct of the system behavior. Conflict !

8. Multidatabase Transaction Management Isolated Histories A history implies a dependency relation (time order) among the transactions r 1 (a) c 1 w 3 (a) r 2 (b) c 2 w 3 (b) c 3 Two histories for the same set of transactions are equivalent if they have the same dependency relation. A history is said to be isolated if it is equivalent to a serial history. T1T1 T2T2 T3T3

9. Multidatabase Transaction Management Isolation Theory A transaction should: 1. Be well-formed: it should cover all actions with locks 2. Set XLOCK on any data it writes. 3. Be 2-phase: it should not release locks until it knows it needs no more locks. 4. Hold XLOCKs until COMMIT or ROLLBACK. If these rules are followed, the execution history will give each transaction the illusion it is running in isolation.

10. Multidatabase Transaction Management Local vs. Global Transactions Local Transactions:  Access data managed by only a single DBMS  Executed outside of MDBS control Global Transactions:  Consists of a number of subtransactions  Subtransactions are processed as local transactions

11. Multidatabase Transaction Management Mutidatabase Environment Each local DBMS ensures the ACID properties at its site  Consistency & Isolation: Each local DBMS generates a serializable schedule consisting of operations of local and global transactions that were executed at its site  Atomicity and Durability: Each local DBMS uses some form of recovery scheme, e.g., write-ahead log protocol (all transaction log records associated with a particular data page must be flushed to disk before the data page itself can be flushed to disk)

12. Multidatabase Transaction Management Three Types of Autonomy The MDBS considers each local DBMS as a blackbox that operates autonomously  Design Autonomy: No changes can be made to the local DBMS software to accommodate the MDBS  Execution Autonomy: Each local DBMS retains complete control over the execution of transactions at its site (e.g., abort a transaction)  Communication Autonomy: Local DBMSs are not able to coordinate the actions of global transactions executing at several sites. (Local DBMSs do not share control information)

13. Multidatabase Transaction Management Interface MDBS Knowledge of internals of local DBMS’s DBMS 1 uses 2PL Transaction Operations Status Information Operations DBMS 1 Transaction Operations Status Information Operations DBMS n...

14. Multidatabase Transaction Management Transaction Operations: Examples Begin Transaction: MDBS initiates a new local transaction. The DBMS returns a TID End Transaction: The identified transaction may be committed Read/Write: Perform indicated action Abort: Terminate and abort a transaction Commit: Make all changes permanent Prepare to Commit: The identified transaction has finished its actions and is ready to commit Service Request: The execution of a procedure is requested (equivalent to submitting all actions of a local transaction, from begin transaction to commit, at once.)

15. Multidatabase Transaction Management Status Information Operations: Examples Inquire: Find out status (e.g., commit, abort) of a transaction Disable Transaction Class: Certain types of transactions (e.g., identified by read or write access sets) are not allowed to commit at this box  The operations define a spectrum of autonomy  The more autonomy the DBMSs retain, the harder it is to guarantee global data consistency

16. Multidatabase Transaction Management Local Servers The servers converts the subtransactions for each local database system (LDBS) into a form usable by the LDBS Global Transaction Manager (GTM) TiTi TjTj } Global transactions Server DBMS Server DBMS T i1 T j2 T j1 T in Local transaction

17. Multidatabase Transaction Management Definitions Projection: A projection of schedule on a set of transactions T is a subschedule that contains only operations of transactions from T S: … r 1 (a) r 3 (d) r 2 (g) r 4 (g) w 3 (e) r 2 (f) w 1 (b) w 4 (k) w 2 (l) … T = {T 2, T 4 }  T (S): r 2 (g) r 4 (g) r 2 (f) w 4 (k) w 2 (l) /* Projection on T */ Committed Projection: A committed projection of a schedule is a subschedule that contains only operations of committed transactions

18. Multidatabase Transaction Management Local Serializable Schedule A local serialization (dependency) graph for schedule S k is a directed graph with  nodes corresponding to global and local transactions, and  a set of edges such that T i →T j if T i conflicts with T j Schedule S k is serializable if and only if its local serialization graph is acyclic (equivalent to some serial schedule)

19. Multidatabase Transaction Management Global Schedule T(k) is the set of transactions at site k S k is the local schedule at site k A global schedule S is a partial ordered set of all operations belonging to local and global transactions such that,  T(k) (S) = S k for all k /* Projection on the local transactions is the local schedule */

20. Multidatabase Transaction Management Globally Serializable Global Serialization Graph: A union of local serialization graphs is called a global serialization graph Globally serializable: A global schedule is globally serializable if and only if its global serialization graph is acyclic (therefore equivalent to some serial schedule)

21. Multidatabase Transaction Management Multidatabase Transaction Management Issues Global Serializability Problem Global Atomicity and Recovery Problems Global Deadlock Problem

22. Multidatabase Transaction Management Global Serialization If each local database uses 2PL, then global execution is serializable If some of the local databases do not use 2PL, we need techniques to force consistent serialization at each site

23. Multidatabase Transaction Management Global Serialization Example (1) b a T3T3 1 st write 2 nd write T1T1 1 st read Site S 1 dc T4T4 1 st write 2 nd write T2T2 1 st read Site S 2 2 nd read 2 nd read Local Schedule S 1 : r 1 (a) c 1 w 3 (a) w 3 (b) c 3 r 2 (b) c 2 Local Schedule S 2 : w 4 (c) r 1 (c) c 1 r 2 (d) c 2 w 4 (d) c 4 GTM: At every site, executes T 2 after T 1 completes - Guarantee global serializability ?

24. Multidatabase Transaction Management Global Serialization Problem (2) T3T3 T1T1 T2T2 T1T1 T4T4 T2T2 T3T3 T1T1 T2T2 T4T4 Serialization Graph at S 1 Serialization Graph at S 2 Global Serialization Graph Even serial execution of global transactions at each site does not guarantee global serializability The problem may arise because local transactions can create indirect conflict between global transactions Local Schedule S 1 : r 1 (a) c 1 w 3 (a) w 3 (b) c 3 r 2 (b) c 2 Local Schedule S 2 : w 4 (c) r 1 (c) c 1 r 2 (d) c 2 w 4 (d) c 4

25. Multidatabase Transaction Management All Sites Use 2PL T3T3 T1T1 T2T2 T1T1 T4T4 T2T2 T3T3 T1T1 T2T2 T4T4 Serialization Graph at S 1 Serialization Graph at S 2 Global Serialization Graph Note: This scenario could have not happen if all local database uses 2PL Local Schedule S 1 : r 1 (a) c 1 w 3 (a) w 3 (b) c 3 r 2 (b) c 2 Local Schedule S 2 : w 4 (c) r 1 (c) c 1 r 2 (d) c 2 w 4 (d) c 4 T4 must have released the lock T4 acquires another lock  Violate 2PL

26. Multidatabase Transaction Management Global Atomicity & Recovery Problems Site S 1 has data item a, and site S 2 has item c.  Consider global transaction T 1 : r 1 (a) w 1 (a) w 1 (c) T 1 sends commit requests to both sites However, S 1, after reading, decides to abort before the commit arrives  After this is accomplished, a local transaction “T 2 : r 2 (a) w 2 (a) c 2 ” is executed and committed at site S 1  The GTM attempts to redo the w 1 (a) of T 1 S 1 viewpoint: the redo w 1 (a) is a new transaction T 3 MDBS viewpoint: T 3 ’s write operation is the same as w 1 (a) We have a non-serializable schedule: S 1 : r 1 (a) r 2 (a) w 2 (a) w 1 (a) T 2 T 1 The problem can be avoided if the local DBMSs provide a prepare-to-commit operation (T 1 would be resubmitted as a new transaction). However, this will violate the execution autonomy requirement Site S 1 Site S 2 Site S1

27. Multidatabase Transaction Management Global Deadlock Problem S 1 has data items a and b, and S 2 has data items c and d Both sites use 2PL protocol Global Trans. Local Trans. T1T1 T2T2 T3T3 T4T4 r1(a)r1(a) r2(c)r2(c) r2(b)r2(b) r1(d)r1(d) w4(c)w4(c)w4(d)w4(d) w3(a)w3(a)w3(b)w3(b) Wait-for Graph: T1 T3 T2 T4 Local DBMSs may not wish to exchange their control information and therefore will be unaware of the global deadlock Similarly, the MDBS is not aware of local transactions and, therefore, will be also unaware of the deadlock time Wait

28. Multidatabase Transaction Management Addressing Global Serializability Problem Observation: Local transactions may generate indirect conflicts between global transactions that otherwise are not in conflict Can we delay global transactions to avoid cycles in serialization graph ? T3T3 T1T1 T2T2 T4T4 Delay T 2 until T 4 completes to avoid the conflict T 2 → T 4  Not possible, GTM has no way of knowing about T 4  A solution is “forcing conflicts” T1 & T2 are global transactions

29. Multidatabase Transaction Management Forcing Conflicts - Idea Problem: T 1 is serialized before T 2 at S 1, and after T 2 at S 2 ; hence global serialization is not maintained Idea: Force “T 1 →T 2 ” at all sites How: Force T 1 to write some object at every site it accesses data, and T 2 to read those objects (i.e., forcing conflict) T3T3 T1T1 T2T2 T1T1 T4T4 T2T2 T3T3 T1T1 T2T2 T4T4 Serialization Graph at S 1 Serialization Graph at S 2 Global Serialization Graph

30. Multidatabase Transaction Management Forcing Conflicts - Example GTM executes T 2 after T 1 completes force T 1 to write some object at every site it accesses data, and T 2 to read those objects S 1 : w 1 (o) r 1 (a) c 1 w 3 (a) w 3 (b) c 3 r 2 (o) r 2 (b) c 2 S 2 : w 4 (c) w 1 (o) r 1 (c) c 1 r 2 (o) r 2 (d) c 2 w 4 (d) c 4 T3T3 T1T1 T2T2 T1T1 T4T4 T2T2 Serialization Graph at S 1 Serialization Graph at S 2 F F Site S 2 will not allow this cycle. When T 4 submits w 4 (d), T 4 is aborted. Note: The local sites generate locally serializable schedules

31. Multidatabase Transaction Management More Concurrency – Using Tickets “Forcing Conflicts” works if the global transactions are executed serially If they are executed concurrently, we need to ensure that the local schedules are consistent  We cannot have “T i →T j ” at one site, and “T j →T i ” at another site.  This can be achieved using a special data item, ticket, at each site

32. Multidatabase Transaction Management Ticket A ticket is maintained at each local site Each global transaction executing at a site  reads the ticket value  increment it, and  update the ticket value A ticket value indicates the serialization order of a global transaction at a site

33. Multidatabase Transaction Management Ticket – Optimistic Approach The GTM keeps a serialization graph for all active global transactions (started but not committed) When transaction T reads ticket value t at site S i, an arc is entered from every transaction that reads a ticket less than t at S i to T. (This serialization graph can be maintained by the GTM) If T completes all of its actions and is not involved in a cycle, it is committed, or else it is aborted

34. Multidatabase Transaction Management Ticket - Pessimistic Approach Global transactions are assigned a priori a global serialization order, and the tickets they should read are determined in advance If a transaction submits its operation outside of a local-site ticket order, it waits.  no cycle in the serialization graph !

35. Multidatabase Transaction Management Optimistic vs. Pessimistic Optimistic method may lead to many aborted transactions Pessimistic method may lead to low concurrency Same problem exists with most other techniques An inherent problem in trying to achieve global serializability with autonomous sites.