1. Distributed DBMSSlide 1Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU PMIT-6102 Advanced Database Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University

2. Distributed DBMSSlide 2Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Lecture -11 Distributed Concurrency Control

3. Distributed DBMSSlide 3Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Outline Transaction  Role of the distributed execution monitor Schedule  Detailed Model of the Distributed Execution Monitor, Distributed Concurrency Control  Serializability in Distributed DBMS  Concurrency Control Algorithms  time-stamping,  Deadlock  Centralized Deadlock Detection  Distributed Deadlock Detection

4. Distributed DBMSSlide 4Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU The distributed execution monitor consists of two modules:  a transaction manager (TM) and a scheduler (SC).  The transaction manager is responsible for coordinating the execution of the database operations on behalf of an application.  The scheduler, on the other hand, is responsible for the implementation of a specific concurrency control algorithm for synchronizing access to the database.  A third component that participates in the management of distributed transactions is the local recovery managers (LRM) that exist at each site.  Their function is to implement the local procedures by which the local database can be recovered to a consistent state following a failure. Role of the distributed execution monitor

5. Distributed DBMSSlide 5Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Each transaction originates at one site, which we will call its originating site. The execution of the database operations of a transaction is coordinated by the TM at that transaction’s originating site. The transaction managers implement an interface for the application programs which consists of five commands: begin transaction, read, write, commit, and abort. Role of the distributed execution monitor

6. Distributed DBMSSlide 6Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Begin transaction: This is an indicator to the TM that a new transaction is starting. The TM does some bookkeeping, such as recording the transaction’s name, the originating application, and so on, in coordination with the data processor. Read : If the data item to be read is stored locally, its value is read and returned to the transaction. Otherwise, the TM finds where the data item is stored and requests its value to be returned (after appropriate concurrency control measures are taken). Write : If the data item is stored locally, its value is updated (in coordination with the data processor). Otherwise, the TM finds where the data item is located and requests the update to be carried out at that site after appropriate concurrency control measures are taken). Commit : The TM coordinates the sites involved in updating data items on behalf of this transaction so that the updates are made permanent at every site. Abort The TM makes sure that no effects of the transaction are reflected in any of the databases at the sites where it updated data items. Role of the distributed execution monitor

7. Distributed DBMSSlide 7Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Detailed Model of the Distributed Execution Monitor Scheduling/ Descheduling Requests Transaction Manager (TM) Distributed Execution Monitor With other SCs With other TMs Begin_transaction, Read, Write, Commit, Abort To data processor Results Scheduler (SC)

8. Distributed DBMSSlide 8Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Serializability in Distributed DBMS Somewhat more involved. Two histories have to be considered:  local histories  global history For global transactions (i.e., global history) to be serializable, two conditions are necessary:  Each local history should be serializable.  Two conflicting operations should be in the same relative order in all of the local histories where they appear together.

9. Distributed DBMSSlide 9Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Global Non-serializability The following two local histories are individually serializable (in fact serial), but the two transactions are not globally serializable. T 1 :Read( x ) T 2 :Read( x ) x  x  5 x  x  15 Write( x )Write( x )Commit LH 1 ={ R 1 ( x ), W 1 ( x ), C 1, R 2 ( x ), W 2 ( x ), C 2 } LH 2 ={ R 2 (x), W 2 (x), C 2, R 1 (x), W 1 (x), C 1 }

10. Distributed DBMSSlide 10Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Concurrency Control Algorithms Pessimistic  Two-Phase Locking-based (2PL)  Centralized (primary site) 2PL  Primary copy 2PL  Distributed 2PL  Timestamp Ordering (TO)  Basic TO  Multiversion TO  Conservative TO  Hybrid Optimistic  Locking-based  Timestamp ordering-based

11. Distributed DBMSSlide 11Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Locking-Based Algorithms Transactions indicate their intentions by requesting locks from the scheduler (called lock manager). Locks are either read lock ( rl ) [also called shared lock] or write lock ( wl ) [also called exclusive lock] Read locks and write locks conflict (because Read and Write operations are incompatible rl wl rl yesno wl nono Locking works nicely to allow concurrent processing of transactions.

12. Distributed DBMSSlide 12Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Two-Phase Locking (2PL)  A Transaction locks an object before using it.  When an object is locked by another transaction, the requesting transaction must wait.  When a transaction releases a lock, it may not request another lock. Obtain lock Release lock Lock point Phase 1Phase 2 BEGINEND No. of locks

13. Distributed DBMSSlide 13Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Strict 2PL Hold locks until the end. Obtain lock Release lock BEGINEND Transaction duration period of data item use

14. Distributed DBMSSlide 14Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Testing for Serializability Consider transactions T 1, T 2, …, T k Create a directed graph (called a conflict graph), whose nodes are transactions. Consider a history of transactions. If T 1 unlocks an item and T 2 locks it afterwards, draw an edge from T 1 to T 2 implying T 1 must precede T 2 in any serial history T 1 →T 2 Repeat this for all unlock and lock actions for different transactions. If graph has a cycle, the history is not serializable. If graph is a cyclic, a topological sorting will give the serial history.

15. Distributed DBMSSlide 15Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Example T 1 :Lock X T 1 : Unlock X T 2 :Lock X T 2 : Lock Y T 2 : Unlock X T 2 :Unlock Y T 3 :Lock Y T 3 :Unlock Y T 1 →T 2 T 2 →T 3 T2T2 T1T1 T3T3

16. Distributed DBMSSlide 16Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Theorem Two phase locking is a sufficient condition to ensure serializablility. Proof: By contradiction. If history is not serializable, a cycle must exist in the conflict graph. This means the existence of a path such as T 1 →T 2 →T 3 … T k → T 1. This implies T 1 unlocked before T 2 and after T k. T 1 requested a lock again. This violates the condition of two phase locking.

17. Distributed DBMSSlide 17Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Only one of the sites has a lock manager; The transaction managers at the other sites communicate with it rather than with their own lock managers. This approach is also known as the primary site 2PL algorithm The communication between the cooperating sites in executing a transaction A centralized 2PL (C2PL) algorithm is depicted in Figure in next slide. This communication is between  the transaction manager at the site where the transaction is initiated (called the coordinating TM), the lock manager at the central site, and the data processors (DP) at the other participating sites.  The participating sites are those that store the data item and at which the operation is to be carried out.  The order of messages is denoted in the figure. Centralized 2PL

18. Distributed DBMSSlide 18Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Centralized 2PL There is only one 2PL scheduler in the distributed system. Lock requests are issued to the central scheduler. Data Processors at participating sites Coordinating TMCentral Site LM Lock Request Lock Granted Operation End of Operation Release Locks

19. Distributed DBMSSlide 19Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Distributed 2PL 2PL schedulers are placed at each site. Each scheduler handles lock requests for data at that site. A transaction may read any of the replicated copies of item x, by obtaining a read lock on one of the copies of x. Writing into x requires obtaining write locks for all copies of x.

20. Distributed DBMSSlide 20Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Distributed 2PL Execution Coordinating TMParticipating LMsParticipating DPs Lock Request Operation End of Operation Release Locks

21. Distributed DBMSSlide 21Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Timestamp Ordering Transaction ( T i ) is assigned a globally unique timestamp ts ( T i ). Transaction manager attaches the timestamp to all operations issued by the transaction. Each data item is assigned a write timestamp ( wts ) and a read timestamp ( rts ):  rts ( x ) = largest timestamp of any read on x  wts ( x ) = largest timestamp of any read on x Conflicting operations are resolved by timestamp order. Basic T/O: for R i ( x )for W i ( x ) if ts ( T i ) < wts ( x ) if ts ( T i ) < rts ( x ) and ts ( T i ) < wts ( x ) then reject R i ( x ) then reject W i ( x ) else accept R i ( x ) else accept W i ( x ) rts ( x )  ts ( T i ) wts ( x )  ts ( T i )

22. Distributed DBMSSlide 22Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Transaction execution model: divide into subtransactions each of which execute at a site  T ij : transaction T i that executes at site j Transactions run independently at each site until they reach the end of their read phases All subtransactions are assigned a timestamp at the end of their read phase Validation test performed during validation phase. If one fails, all rejected. Optimistic Concurrency Control Algorithms

23. Distributed DBMSSlide 23Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Start Read, Compute, And Write Local Semi-Commit On Initiating Site Integrity Control & Local Validation Integrity Control & Local Validation Commit, Global Write Finish Fail Success Fail Success Optimistic Concurrency Control Processing

24. Distributed DBMSSlide 24Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Optimistic CC Validation Test If all transactions T k where ts ( T k ) < ts ( T ij ) have completed their write phase before T ij has started its read phase, then validation succeeds  Transaction executions in serial order TkTk RVW RVW T ij

25. Distributed DBMSSlide 25Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Optimistic CC Validation Test If there is any transaction T k such that ts ( T k )< ts ( T ij ) and which completes its write phase while T ij is in its read phase, then validation succeeds if WS ( T k )  RS ( T ij ) = Ø  Read and write phases overlap, but T ij does not read data items written by T k RVW TkTk RVW T ij

26. Distributed DBMSSlide 26Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Optimistic CC Validation Test If there is any transaction T k such that ts ( T k )< ts ( T ij ) and which completes its read phase before T ij completes its read phase, then validation succeeds if WS ( T k )  RS ( T ij ) = Ø and WS ( T k )  WS ( T ij ) = Ø  They overlap, but don't access any common data items. RVW TkTk RVW T ij

27. Distributed DBMSSlide 27Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU A transaction is deadlocked if it is blocked and will remain blocked until there is intervention. Locking-based CC algorithms may cause deadlocks. TO-based algorithms that involve waiting may cause deadlocks. Wait-for graph  If transaction T i waits for another transaction T j to release a lock on an entity, then T i  T j in WFG. Deadlock TiTi TjTj

28. Distributed DBMSSlide 28Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Assume T 1 and T 2 run at site 1, T 3 and T 4 run at site 2. Also assume T 3 waits for a lock held by T 4 which waits for a lock held by T 1 which waits for a lock held by T 2 which, in turn, waits for a lock held by T 3. Local WFG Global WFG Local versus Global WFG T1T1 Site 1 Site 2 T2T2 T4T4 T3T3 T1T1 T2T2 T4T4 T3T3

29. Distributed DBMSSlide 29Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Ignore  Let the application programmer deal with it, or restart the system Prevention  Guaranteeing that deadlocks can never occur in the first place. Check transaction when it is initiated. Requires no run time support. Avoidance  Detecting potential deadlocks in advance and taking action to insure that deadlock will not occur. Requires run time support. Detection and Recovery  Allowing deadlocks to form and then finding and breaking them. As in the avoidance scheme, this requires run time support. Deadlock Management

30. Distributed DBMSSlide 30Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Transactions are not required to request resources a priori. Transactions are allowed to proceed unless a requested resource is unavailable. In case of conflict, transactions may be allowed to wait for a fixed time interval. Order either the data items or the sites and always request locks in that order. More attractive than prevention in a database environment. Deadlock Avoidance

31. Distributed DBMSSlide 31Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU WAIT-DIE Rule: If T i requests a lock on a data item which is already locked by T j, then T i is permitted to wait iff ts ( T i ) ts ( T j ), then T i is aborted and restarted with the same timestamp.  if ts ( T i )< ts ( T j ) then T i waits else T i dies  non-preemptive: T i never preempts T j  prefers younger transactions WOUND-WAIT Rule: If T i requests a lock on a data item which is already locked by T j, then T i is permitted to wait iff ts ( T i )> ts ( T j ). If ts ( T i )< ts ( T j ), then T j is aborted and the lock is granted to T i.  if ts ( T i )< ts ( T j ) then T j is wounded else T i waits  preemptive: T i preempts T j if it is younger  prefers older transactions Deadlock Avoidance – Wait-Die & Wound-Wait Algorithms

32. Distributed DBMSSlide 32Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Transactions are allowed to wait freely. Wait-for graphs and cycles. Topologies for deadlock detection algorithms  Centralized  Distributed  Hierarchical Deadlock Detection

33. Distributed DBMSSlide 33Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU One site is designated as the deadlock detector for the system. Each scheduler periodically sends its local WFG to the central site which merges them to a global WFG to determine cycles. How often to transmit?  Too often  higher communication cost but lower delays due to undetected deadlocks  Too late  higher delays due to deadlocks, but lower communication cost Would be a reasonable choice if the concurrency control algorithm is also centralized. Proposed for Distributed INGRES Centralized Deadlock Detection

34. Distributed DBMSSlide 34Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Sites cooperate in detection of deadlocks. One example:  The local WFGs are formed at each site and passed on to other sites. Each local WFG is modified as follows:  Since each site receives the potential deadlock cycles from other sites, these edges are added to the local WFGs  The edges in the local WFG which show that local transactions are waiting for transactions at other sites are joined with edges in the local WFGs which show that remote transactions are waiting for local ones.  Each local deadlock detector:  looks for a cycle that does not involve the external edge. If it exists, there is a local deadlock which can be handled locally.  looks for a cycle involving the external edge. If it exists, it indicates a potential global deadlock. Pass on the information to the next site. Distributed Deadlock Detection

35. Distributed DBMSSlide 35Lectured by, Jesmin Akhter, Assistant Professor, IIT, JU Thank you