1. Distributed DBMSPage 10-12. 1© 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database Design Semantic Data Control Distributed Query Processing  Distributed Transaction Management  Transaction Concepts and Models  Distributed Concurrency Control  Distributed Reliability  Parallel Database Systems  Distributed Object DBMS  Database Interoperability  Concluding Remarks

2. Distributed DBMSPage 10-12. 2© 1998 M. Tamer Özsu & Patrick Valduriez Transaction A transaction is a collection of actions that make consistent transformations of system states while preserving system consistency.  concurrency transparency  failure transparency Database in a consistent state Database may be temporarily in an inconsistent state during execution Begin Transaction End Transaction Execution of Transaction Database in a consistent state

3. Distributed DBMSPage 10-12. 3© 1998 M. Tamer Özsu & Patrick Valduriez Transaction Example – A Simple SQL Query Transaction BUDGET_UPDATE begin EXEC SQLUPDATEPROJ SET BUDGET = BUDGET  1.1 WHEREPNAME = “CAD/CAM” end.

4. Distributed DBMSPage 10-12. 4© 1998 M. Tamer Özsu & Patrick Valduriez Example Database Consider an airline reservation example with the relations: FLIGHT(FNO, DATE, SRC, DEST, STSOLD, CAP) CUST(CNAME, ADDR, BAL) FC(FNO, DATE, CNAME,SPECIAL)

5. Distributed DBMSPage 10-12. 5© 1998 M. Tamer Özsu & Patrick Valduriez Example Transaction – SQL Version Begin_transaction Reservation begin input (flight_no, date, customer_name); EXEC SQLUPDATEFLIGHT SETSTSOLD = STSOLD + 1 WHEREFNO = flight_no AND DATE = date; EXEC SQLINSERT INTOFC(FNO, DATE, CNAME, SPECIAL); VALUES(flight_no, date, customer_name, null ); output (“reservation completed”) end. {Reservation}

6. Distributed DBMSPage 10-12. 6© 1998 M. Tamer Özsu & Patrick Valduriez Termination of Transactions Begin_transaction Reservation begin input (flight_no, date, customer_name); EXEC SQLSELECT STSOLD,CAP INTOtemp1,temp2 FROMFLIGHT WHEREFNO = flight_no AND DATE = date; if temp1 = temp2 then output (“no free seats”); Abort else EXEC SQLUPDATEFLIGHT SETSTSOLD = STSOLD + 1 WHEREFNO = flight_no AND DATE = date; EXEC SQLINSERT INTOFC(FNO, DATE, CNAME, SPECIAL); VALUES(flight_no, date, customer_name, null ); Commit output (“reservation completed”) endif end. {Reservation}

7. Distributed DBMSPage 10-12. 7© 1998 M. Tamer Özsu & Patrick Valduriez Example Transaction – Reads & Writes Begin_transaction Reservation begin input (flight_no, date, customer_name); temp  Read(flight_no(date).stsold); if temp = flight(date).cap then begin output (“no free seats”); Abort end else begin Write(flight(date).stsold, temp + 1); Write(flight(date).cname, customer_name); Write(flight(date).special, null ); Commit ; output (“reservation completed”) end end. {Reservation}

8. Distributed DBMSPage 10-12. 8© 1998 M. Tamer Özsu & Patrick Valduriez Characterization Read set (RS)  The set of data items that are read by a transaction Write set (WS)  The set of data items whose values are changed by this transaction Base set (BS)  RS  WS

9. Distributed DBMSPage 10-12. 9© 1998 M. Tamer Özsu & Patrick Valduriez Let  O ij ( x ) be some operation O j of transaction T i operating on entity x, where O j  {read,write} and O j is atomic  OS i =  j O ij  N i  {abort,commit} Transaction T i is a partial order T i = {  i, < i } where   i = OS i  { N i }  For any two operations O ij, O ik  OS i, if O ij = R ( x ) and O ik = W ( x ) for any data item x, then either O ij < i O ik or O ik < i O ij   O ij  OS i, O ij < i N i Formalization

10. Distributed DBMSPage 10-12. 10© 1998 M. Tamer Özsu & Patrick Valduriez Consider a transaction T : Read( x ) Read( y ) x  x + y Write( x ) Commit Then  = { R ( x ), R ( y ), W ( x ), C } < = {( R ( x ), W ( x )), ( R ( y ), W ( x )), ( W ( x ), C ), ( R ( x ), C ), ( R ( y ), C )} Example

11. Distributed DBMSPage 10-12. 11© 1998 M. Tamer Özsu & Patrick Valduriez Assume < = {( R ( x ), W ( x )), ( R ( y ), W ( x )), ( R ( x ), C ), ( R ( y ), C ), ( W ( x ), C )} DAG Representation R(x)R(x) C R(y)R(y) W(x)W(x)

12. Distributed DBMSPage 10-12. 12© 1998 M. Tamer Özsu & Patrick Valduriez A TOMICITY  all or nothing C ONSISTENCY  no violation of integrity constraints I SOLATION  concurrent changes invisible È serializable D URABILITY  committed updates persist Properties of Transactions

13. Distributed DBMSPage 10-12. 13© 1998 M. Tamer Özsu & Patrick Valduriez Either all or none of the transaction's operations are performed. Atomicity requires that if a transaction is interrupted by a failure, its partial results must be undone. The activity of preserving the transaction's atomicity in presence of transaction aborts due to input errors, system overloads, or deadlocks is called transaction recovery. The activity of ensuring atomicity in the presence of system crashes is called crash recovery. Atomicity

14. Distributed DBMSPage 10-12. 14© 1998 M. Tamer Özsu & Patrick Valduriez Internal consistency  A transaction which executes alone against a consistent database leaves it in a consistent state.  Transactions do not violate database integrity constraints. Transactions are correct programs Consistency

15. Distributed DBMSPage 10-12. 15© 1998 M. Tamer Özsu & Patrick Valduriez Consistency Degrees Degree 0  Transaction T does not overwrite dirty data of other transactions  Dirty data refers to data values that have been updated by a transaction prior to its commitment Degree 1  T does not overwrite dirty data of other transactions  T does not commit any writes before EOT

16. Distributed DBMSPage 10-12. 16© 1998 M. Tamer Özsu & Patrick Valduriez Consistency Degrees (cont’d) Degree 2  T does not overwrite dirty data of other transactions  T does not commit any writes before EOT  T does not read dirty data from other transactions Degree 3  T does not overwrite dirty data of other transactions  T does not commit any writes before EOT  T does not read dirty data from other transactions  Other transactions do not dirty any data read by T before T completes.

17. Distributed DBMSPage 10-12. 17© 1998 M. Tamer Özsu & Patrick Valduriez Isolation Serializability  If several transactions are executed concurrently, the results must be the same as if they were executed serially in some order. Incomplete results  An incomplete transaction cannot reveal its results to other transactions before its commitment.  Necessary to avoid cascading aborts.

18. Distributed DBMSPage 10-12. 18© 1998 M. Tamer Özsu & Patrick Valduriez Isolation Example Consider the following two transactions: T 1 :Read( x ) T 2 :Read( x ) x  x  1 Write( x )Write( x )Commit Possible execution sequences: T 1 :Read( x ) T 1 : x  x  1 T 1 : Write( x ) T 2 :Read( x ) T 1 : Commit T 1 : Write( x ) T 2 :Read( x ) T 2 : x  x  1 T 2 : x  x  1 T 2 :Write( x ) T 2 :Write( x ) T 1 : Commit T 2 :Commit

19. Distributed DBMSPage 10-12. 19© 1998 M. Tamer Özsu & Patrick Valduriez SQL-92 Isolation Levels Phenomena: Dirty read  T 1 modifies x which is then read by T 2 before T 1 terminates; T 1 aborts  T 2 has read value which never exists in the database. Non-repeatable (fuzzy) read  T 1 reads x ; T 2 then modifies or deletes x and commits. T 1 tries to read x again but reads a different value or can’t find it. Phantom  T 1 searches the database according to a predicate while T 2 inserts new tuples that satisfy the predicate.

20. Distributed DBMSPage 10-12. 20© 1998 M. Tamer Özsu & Patrick Valduriez SQL-92 Isolation Levels (cont’d) Read Uncommitted  For transactions operating at this level, all three phenomena are possible. Read Committed  Fuzzy reads and phantoms are possible, but dirty reads are not. Repeatable Read  Only phantoms possible. Anomaly Serializable  None of the phenomena are possible.

21. Distributed DBMSPage 10-12. 21© 1998 M. Tamer Özsu & Patrick Valduriez Once a transaction commits, the system must guarantee that the results of its operations will never be lost, in spite of subsequent failures. Database recovery Durability

22. Distributed DBMSPage 10-12. 22© 1998 M. Tamer Özsu & Patrick Valduriez Based on  Application areas  non-distributed vs. distributed  compensating transactions  heterogeneous transactions  Timing  on-line (short-life) vs batch (long-life)  Organization of read and write actions  two-step  restricted  action model  Structure  flat (or simple) transactions  nested transactions  workflows Characterization of Transactions

23. Distributed DBMSPage 10-12. 23© 1998 M. Tamer Özsu & Patrick Valduriez Transaction Structure Flat transaction  Consists of a sequence of primitive operations embraced between a begin and end markers. Begin_transaction Reservation … end. Nested transaction  The operations of a transaction may themselves be transactions. Begin_transaction Reservation … Begin_transaction Airline –… end. {Airline} Begin_transaction Hotel … end. {Hotel} end. {Reservation}

24. Distributed DBMSPage 10-12. 24© 1998 M. Tamer Özsu & Patrick Valduriez Have the same properties as their parents  may themselves have other nested transactions. Introduces concurrency control and recovery concepts to within the transaction. Types  Closed nesting  Subtransactions begin after their parents and finish before them.  Commitment of a subtransaction is conditional upon the commitment of the parent (commitment through the root).  Open nesting  Subtransactions can execute and commit independently.  Compensation may be necessary. Nested Transactions

25. Distributed DBMSPage 10-12. 25© 1998 M. Tamer Özsu & Patrick Valduriez Workflows “A collection of tasks organized to accomplish some business process.” [D. Georgakopoulos] Types  Human-oriented workflows  Involve humans in performing the tasks.  System support for collaboration and coordination; but no system-wide consistency definition  System-oriented workflows  Computation-intensive & specialized tasks that can be executed by a computer  System support for concurrency control and recovery, automatic task execution, notification, etc.  Transactional workflows  In between the previous two; may involve humans, require access to heterogeneous, autonomous and/or distributed systems, and support selective use of ACID properties

26. Distributed DBMSPage 10-12. 26© 1998 M. Tamer Özsu & Patrick Valduriez Workflow Example T1T1 T2T2 T3T3 T4T4 T5T5 Customer Database Customer Database Customer Database T 1 : Customer request obtained T 2 :Airline reservation performed T 3 :Hotel reservation performed T 4 : Auto reservation performed T 5 : Bill generated

27. Distributed DBMSPage 10-12. 27© 1998 M. Tamer Özsu & Patrick Valduriez Transactions Provide… Atomic and reliable execution in the presence of failures Correct execution in the presence of multiple user accesses Correct management of replicas (if they support it)

28. Distributed DBMSPage 10-12. 28© 1998 M. Tamer Özsu & Patrick Valduriez Transaction Processing Issues Transaction structure (usually called transaction model)  Flat (simple), nested Internal database consistency  Semantic data control (integrity enforcement) algorithms Reliability protocols  Atomicity & Durability  Local recovery protocols  Global commit protocols

29. Distributed DBMSPage 10-12. 29© 1998 M. Tamer Özsu & Patrick Valduriez Transaction Processing Issues Concurrency control algorithms  How to synchronize concurrent transaction executions (correctness criterion)  Intra-transaction consistency, Isolation Replica control protocols  How to control the mutual consistency of replicated data  One copy equivalence and ROWA

30. Distributed DBMSPage 10-12. 30© 1998 M. Tamer Özsu & Patrick Valduriez Architecture Revisited 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)

31. Distributed DBMSPage 10-12. 31© 1998 M. Tamer Özsu & Patrick Valduriez Centralized Transaction Execution Begin_Transaction, Read, Write, Abort, EOT Results & User Notifications Scheduled Operations Results … Read, Write, Abort, EOT User Application User Application Transaction Manager (TM) Scheduler (SC) Recovery Manager (RM)

32. Distributed DBMSPage 10-12. 32© 1998 M. Tamer Özsu & Patrick Valduriez Distributed Transaction Execution Begin_transaction, Read, Write, EOT, Abort User application Results & User notifications Read, Write, EOT, Abort TM SC RM SC RM TM Local Recovery Protocol Distributed Concurrency Control Protocol Replica Control Protocol Distributed Transaction Execution Model

33. Distributed DBMSPage 10-12. 33© 1998 M. Tamer Özsu & Patrick Valduriez Concurrency Control The problem of synchronizing concurrent transactions such that the consistency of the database is maintained while, at the same time, maximum degree of concurrency is achieved. Anomalies:  Lost updates  The effects of some transactions are not reflected on the database.  Inconsistent retrievals  A transaction, if it reads the same data item more than once, should always read the same value.

34. Distributed DBMSPage 10-12. 34© 1998 M. Tamer Özsu & Patrick Valduriez Execution Schedule (or History) An order in which the operations of a set of transactions are executed. A schedule (history) can be defined as a partial order over the operations of a set of transactions. H 1 ={ W 2 ( x ), R 1 ( x ), R 3 ( x ), W 1 ( x ), C 1, W 2 ( y ), R 3 ( y ), R 2 ( z ), C 2, R 3 ( z ), C 3 } T 1 :Read( x ) T 2 :Write( x ) T 3 :Read( x ) Write( x )Write( y )Read( y ) CommitRead( z )Read( z ) CommitCommit

35. Distributed DBMSPage 10-12. 35© 1998 M. Tamer Özsu & Patrick Valduriez A complete schedule SC ( T ) over a set of transactions T ={ T 1, …, T n } is a partial order SC ( T )={  T, < T } where   T =  i  i, for i = 1, 2, …, n  < T   i < i, for i = 1, 2, …, n  For any two conflicting operations O ij, O kl   T, either O ij < T O kl or O kl < T O ij Formalization of Schedule

36. Distributed DBMSPage 10-12. 36© 1998 M. Tamer Özsu & Patrick Valduriez Given three transactions T 1 :Read( x ) T 2 :Write( x ) T 3 :Read( x ) Write( x )Write( y )Read( y ) CommitRead( z )Read( z )Commit A possible complete schedule is given as the DAG Complete Schedule – Example C 1 R3(x)R3(x)R1(x)R1(x)W2(x)W2(x) W1(x)W1(x)W2(y)W2(y)R3(y)R3(y) R3(z)R3(z)R2(z)R2(z) C 2 C 3

37. Distributed DBMSPage 10-12. 37© 1998 M. Tamer Özsu & Patrick Valduriez A schedule is a prefix of a complete schedule such that only some of the operations and only some of the ordering relationships are included. T 1 :Read( x ) T 2 :Write( x ) T 3 :Read( x ) Write( x )Write( y )Read( y ) CommitRead( z )Read( z )Commit Schedule Definition R1(x)R1(x) C 1 R3(x)R3(x) R1(x)R1(x) R3(x)R3(x)W2(x)W2(x)W2(x)W2(x) W1(x)W1(x)W2(y)W2(y)W2(y)W2(y)R3(y)R3(y)R3(y)R3(y) R3(z)R3(z)R3(z)R3(z)R2(z)R2(z)R2(z)R2(z) C 2 C 3 

38. Distributed DBMSPage 10-12. 38© 1998 M. Tamer Özsu & Patrick Valduriez Serial History All the actions of a transaction occur consecutively. No interleaving of transaction operations. If each transaction is consistent (obeys integrity rules), then the database is guaranteed to be consistent at the end of executing a serial history. T 1 :Read( x ) T 2 :Write( x ) T 3 :Read( x ) Write( x )Write( y )Read( y ) CommitRead( z )Read( z ) CommitCommit H s ={ W 2 ( x ), W 2 ( y ), R 2 ( z ), C 2, R 1 ( x ), W 1 ( x ), C 1, R 3 ( x ), R 3 ( y ), R 3 ( z ), C 3 }

39. Distributed DBMSPage 10-12. 39© 1998 M. Tamer Özsu & Patrick Valduriez Serializable History Transactions execute concurrently, but the net effect of the resulting history upon the database is equivalent to some serial history. Equivalent with respect to what?  Conflict equivalence : the relative order of execution of the conflicting operations belonging to unaborted transactions in two histories are the same.  Conflicting operations : two incompatible operations (e.g., Read and Write) conflict if they both access the same data item.  Incompatible operations of each transaction is assumed to conflict; do not change their execution orders.  If two operations from two different transactions conflict, the corresponding transactions are also said to conflict.

40. Distributed DBMSPage 10-12. 40© 1998 M. Tamer Özsu & Patrick Valduriez Serializable History The following are not conflict equivalent H s ={ W 2 ( x ), W 2 ( y ), R 2 ( z ), C 2, R 1 ( x ), W 1 ( x ), C 1, R 3 ( x ), R 3 ( y ), R 3 ( z ), C 3 } H 1 ={ W 2 ( x ), R 1 ( x ), R 3 ( x ), W 1 ( x ), C 1, W 2 ( y ), R 3 ( y ), R 2 ( z ), C 2, R 3 ( z ), C 3 } The following are conflict equivalent; therefore H 2 is serializable. H s ={ W 2 ( x ), W 2 ( y ), R 2 ( z ), C 2, R 1 ( x ), W 1 ( x ), C 1, R 3 ( x ), R 3 ( y ), R 3 ( z ), C 3 } H 2 ={ W 2 ( x ), R 1 ( x ), W 1 ( x ), C 1, R 3 ( x ), W 2 ( y ), R 3 ( y ), R 2 ( z ), C 2, R 3 ( z ), C 3 } T 1 :Read( x ) T 2 :Write( x ) T 3:Read( x ) Write( x )Write( y )Read( y ) CommitRead( z )Read( z ) CommitCommit

41. Distributed DBMSPage 10-12. 41© 1998 M. Tamer Özsu & Patrick Valduriez 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.

42. Distributed DBMSPage 10-12. 42© 1998 M. Tamer Özsu & Patrick Valduriez 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 }

43. Distributed DBMSPage 10-12. 43© 1998 M. Tamer Özsu & Patrick Valduriez 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

44. Distributed DBMSPage 10-12. 44© 1998 M. Tamer Özsu & Patrick Valduriez 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.

45. Distributed DBMSPage 10-12. 45© 1998 M. Tamer Özsu & Patrick Valduriez 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

46. Distributed DBMSPage 10-12. 46© 1998 M. Tamer Özsu & Patrick Valduriez Strict 2PL Hold locks until the end. Obtain lock Release lock BEGINEND Transaction duration period of data item use

47. Distributed DBMSPage 10-12. 47© 1998 M. Tamer Özsu & Patrick Valduriez 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

48. Distributed DBMSPage 10-12. 48© 1998 M. Tamer Özsu & Patrick Valduriez 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.

49. Distributed DBMSPage 10-12. 49© 1998 M. Tamer Özsu & Patrick Valduriez Distributed 2PL Execution Coordinating TMParticipating LMsParticipating DPs Lock Request Operation End of Operation Release Locks

50. Distributed DBMSPage 10-12. 50© 1998 M. Tamer Özsu & Patrick Valduriez 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 )

51. Distributed DBMSPage 10-12. 51© 1998 M. Tamer Özsu & Patrick Valduriez Basic timestamp ordering tries to execute an operation as soon as it receives it  progressive  too many restarts since there is no delaying Conservative timestamping delays each operation until there is an assurance that it will not be restarted Assurance?  No other operation with a smaller timestamp can arrive at the scheduler  Note that the delay may result in the formation of deadlocks Conservative Timestamp Ordering

52. Distributed DBMSPage 10-12. 52© 1998 M. Tamer Özsu & Patrick Valduriez Multiversion Timestamp Ordering Do not modify the values in the database, create new values. A R i ( x ) is translated into a read on one version of x.  Find a version of x (say x v ) such that ts ( x v ) is the largest timestamp less than ts ( T i ). A W i ( x ) is translated into W i ( x w ) and accepted if the scheduler has not yet processed any R j ( x r ) such that ts ( T i ) < ts ( x r ) < ts ( T j )

53. Distributed DBMSPage 10-12. 53© 1998 M. Tamer Özsu & Patrick Valduriez Optimistic Concurrency Control Algorithms Pessimistic execution Optimistic execution ValidateReadComputeWrite ValidateReadComputeWrite

54. Distributed DBMSPage 10-12. 54© 1998 M. Tamer Özsu & Patrick Valduriez 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

55. Distributed DBMSPage 10-12. 55© 1998 M. Tamer Özsu & Patrick Valduriez 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

56. Distributed DBMSPage 10-12. 56© 1998 M. Tamer Özsu & Patrick Valduriez 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

57. Distributed DBMSPage 10-12. 57© 1998 M. Tamer Özsu & Patrick Valduriez 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

58. Distributed DBMSPage 10-12. 58© 1998 M. Tamer Özsu & Patrick Valduriez 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

59. Distributed DBMSPage 10-12. 59© 1998 M. Tamer Özsu & Patrick Valduriez 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

60. Distributed DBMSPage 10-12. 60© 1998 M. Tamer Özsu & Patrick Valduriez 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

61. Distributed DBMSPage 10-12. 61© 1998 M. Tamer Özsu & Patrick Valduriez All resources which may be needed by a transaction must be predeclared.  The system must guarantee that none of the resources will be needed by an ongoing transaction.  Resources must only be reserved, but not necessarily allocated a priori  Unsuitability of the scheme in database environment  Suitable for systems that have no provisions for undoing processes. Evaluation: –Reduced concurrency due to preallocation –Evaluating whether an allocation is safe leads to added overhead. –Difficult to determine (partial order) +No transaction rollback or restart is involved. Deadlock Prevention

62. Distributed DBMSPage 10-12. 62© 1998 M. Tamer Özsu & Patrick Valduriez 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

63. Distributed DBMSPage 10-12. 63© 1998 M. Tamer Özsu & Patrick Valduriez 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

64. Distributed DBMSPage 10-12. 64© 1998 M. Tamer Özsu & Patrick Valduriez Transactions are allowed to wait freely. Wait-for graphs and cycles. Topologies for deadlock detection algorithms  Centralized  Distributed  Hierarchical Deadlock Detection

65. Distributed DBMSPage 10-12. 65© 1998 M. Tamer Özsu & Patrick Valduriez 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

66. Distributed DBMSPage 10-12. 66© 1998 M. Tamer Özsu & Patrick Valduriez Build a hierarchy of detectors Hierarchical Deadlock Detection Site 1Site 2Site 3Site 4 DD 21 DD 22 DD 23 DD 24 DD 11 DD 14 DD ox

67. Distributed DBMSPage 10-12. 67© 1998 M. Tamer Özsu & Patrick Valduriez 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

68. Distributed DBMSPage 10-12. 68© 1998 M. Tamer Özsu & Patrick Valduriez Problem: How to maintain atomicity durability properties of transactions Reliability

69. Distributed DBMSPage 10-12. 69© 1998 M. Tamer Özsu & Patrick Valduriez Reliability  A measure of success with which a system conforms to some authoritative specification of its behavior.  Probability that the system has not experienced any failures within a given time period.  Typically used to describe systems that cannot be repaired or where the continuous operation of the system is critical. Availability  The fraction of the time that a system meets its specification.  The probability that the system is operational at a given time t. Fundamental Definitions

70. Distributed DBMSPage 10-12. 70© 1998 M. Tamer Özsu & Patrick Valduriez External state Internal state Component 2 ENVIRONMENT SYSTEM StimuliResponses Component 1 Component 3 Basic System Concepts

71. Distributed DBMSPage 10-12. 71© 1998 M. Tamer Özsu & Patrick Valduriez Failure  The deviation of a system from the behavior that is described in its specification. Erroneous state  The internal state of a system such that there exist circumstances in which further processing, by the normal algorithms of the system, will lead to a failure which is not attributed to a subsequent fault. Error  The part of the state which is incorrect. Fault  An error in the internal states of the components of a system or in the design of a system. Fundamental Definitions

72. Distributed DBMSPage 10-12. 72© 1998 M. Tamer Özsu & Patrick Valduriez Faults to Failures FaultErrorFailure causesresults in

73. Distributed DBMSPage 10-12. 73© 1998 M. Tamer Özsu & Patrick Valduriez Hard faults  Permanent  Resulting failures are called hard failures Soft faults  Transient or intermittent  Account for more than 90% of all failures  Resulting failures are called soft failures Types of Faults