1. Chapter 91 Chapter 9. Concurrency Control Fall 2001 Prof. Sang Ho Lee School of Computing, Soongsil Univ. shlee@computing.soongsil.ac.kr

2. Chapter 92 Overview (1) Even when there is no “failure”, several transactions can interact to turn a consistent state into an inconsistent state Scheduler performs a function of controlling transactions’ execution. In some situations, the scheduler must delay the request. In some concurrency control techniques, the scheduler may even abort the transaction

3. Chapter 93 Overview (2) Buffers Transaction Manager Transaction Manager Scheduler Read/Write requests Reads and writes

4. Chapter 94 Overview (3) Concurrency Control –The general process of assuring that transactions preserve consistency when executing simultaneously Here, we talk about: –Serializability, conflict-serializability –Locking, 2PL, Lock granularity, deadlock, … –No discussion about timestamping, validation

5. Chapter 95 Problem with nonserializable execution (1) There are three cases in which nonserializable execution causes problems, concurrency anomalies Dirty read T1T2 Write(A) Read(A) A = A+50 Write(A) Rollback

6. Chapter 96 Problem with nonserializable execution (2) Lost updateUnrepeatable read T1T2 Read(A) A = A+50 Read(A) A = A+50 Write(A) T1T2 Read(A) A = A+50 Write(A) Read(A)

7. Chapter 97 Schedules Recall the consistency property (assumption) of the ACID, which states that every transaction will transform any consistent state to another consistent state if executed in isolation (without any other transactions running concurrently) Schedule (history): a time-ordered sequence of the important actions taken by one or more transactions

8. Chapter 98 Example 9.1 (1/2) Assume A=B is required for consistency Two transactions: T 1 READ(A, t) t := t+100 WRITE(A, t) READ(B, t) t := t+100 WRITE(B, t) T 2 READ(A, s) s := s*2 WRITE(A, s) READ(B, s) s := s*2 WRITE(B, s)

9. Chapter 99 Serial schedules A schedule is serial if its actions consist of all the actions of one transaction, then all the actions of another transaction, and so on, with no mixing of the actions

10. Chapter 910 Example 9.2 (1): serial schedule T 1 READ(A, t) t := t+100 WRITE(A, t) READ(B, t) t := t+100 WRITE(B, t) T 2 READ(A, s) s := s*2 WRITE(A, s) READ(B, s) s := s*2 WRITE(B, s) A 25 125 250 B 25 125 250

11. Chapter 911 Example 9.2 (2): serial schedule T 1 READ(A, t) t := t+100 WRITE(A, t) READ(B, t) t := t+100 WRITE(B, t) T 2 READ(A, s) s := s*2 WRITE(A, s) READ(B, s) s := s*2 WRITE(B, s) A 25 50 150 B 25 50 150

12. Chapter 912 Serializable Schedules A schedule is serializable if its effect on the database state is the same as that of some serial schedule, regardless of what the initial state of the database is

13. Chapter 913 Example 9.3 (1) - serializable, not serial T 1 READ(A, t) t := t+100 WRITE(A, t) READ(B, t) t := t+100 WRITE(B, t) T 2 READ(A, s) s := s*2 WRITE(A, s) READ(B, s) s := s*2 WRITE(B, s) A 25 125 250 B 25 125 250

14. Chapter 914 Example 9.3 (2) – nonserializable T 1 READ(A, t) t := t+100 WRITE(A, t) READ(B, t) t := t+100 WRITE(B, t) T 2 READ(A, s) s := s*2 WRITE(A, s) READ(B, s) s := s*2 WRITE(B, s) A 25 125 250 B 25 50 150

15. Chapter 915 Notations (1) We focus on the reads and writes only, assuming that whenever transaction T reads X and then write it, X has changed in some unique way r T (X) : transaction T reads DB element X w T (X) : transaction T writes X If transactions are T 1, …, T k, then r i and w i are used instead of r T i, w T i The transactions (see slide 6) can be written, –T 1 : r 1 (A); w 1 (A); r 1 (B); w 1 (B); –T 2 : r 2 (A); w 2 (A); r 2 (B); w 2 (B); Example 9.3 (1) Fig. 9.5 can be written, –r 1 (A); w 1 (A); r 2 (A); w 2 (A); r 1 (B); w 1 (B); r 2 (B); w 2 (B);

16. Chapter 916 Notations (2) Action r i (X), w i (X) –Transaction T i reads or writes the database element X Transaction T i –A sequence of actions on database elements Schedule S –A sequence of read/write events performed by a collection of transactions

17. Chapter 917 Conflicts (1) Conflict: a pair of consecutive actions in a schedule such that, if their order is interchanged, then the behavior of at least one of the transactions involved can change Non-conflicting examples –r i (X); r j (Y) even if X = Y –r i (X); w j (Y) if X ≠ Y –w i (X); w j (Y) if X ≠ Y

18. Chapter 918 Conflicts (2) A read and a write of the same X, or two writes of X conflict and may not be swapped in order. All other events may be swapped without the possibility that the effect of the schedule will change Two schedules are conflict-equivalent if two schedules can be turned one into the other by a sequence of nonconflicting swaps of adjacent actions A schedule is conflict-serializable if a schedule is conflict-equivalent to a serial schedule

19. Chapter 919 Example 9.6 r 1 (A); w 1 (A); r 2 (A); w 2 (A); r 1 (B); w 1 (B); r 2 (B); w 2 (B); → r 1 (A); w 1 (A); r 2 (A); r 1 (B); w 2 (A); w 1 (B); r 2 (B); w 2 (B); → r 1 (A); w 1 (A); r 1 (B); r 2 (A); w 2 (A); w 1 (B); r 2 (B); w 2 (B); → r 1 (A); w 1 (A); r 1 (B); r 2 (A); w 1 (B); w 2 (A); r 2 (B); w 2 (B); → r 1 (A); w 1 (A); r 1 (B); w 1 (B); r 2 (A); w 2 (A); r 2 (B); w 2 (B); Hence, the above schedule is conflict-serializable

20. Chapter 920 Why conflict-serializability is not necessary for serializability Conflict-serializability is a sufficient condition for serializability –Conflict-serializability is not required for a schedule to be serializable Consider S 1 : w 1 (Y); w 1 (X); w 2 (Y); w 2 (X); w 3 (X); // serial schedule S 2 : w 1 (Y); w 2 (Y); w 2 (X); w 1 (X); w 3 (X); –S 1 and S 2 leave X and Y with the same value !!! –S2 is serializable, but not conflict-serializable We cannot swap w 1 (Y); w 2 (Y); and w 2 (X); w 1 (X);

21. Chapter 921 Precedence (Dependency) Graph (1) Given a schedule S, involving T 1 and T 2, perhaps among other transactions, we say that T 1 takes precedence over T 2 (T 1 < S T 2 ), if there are actions A 1 of T 1 and A 2 of T 2 –A 1 is ahead of A 2 in S –Both A 1 and A 2 involve the same database element –At least one of A 1 and A 2 is a write action A 1 will appear before A 2 in any schedule that is conflict-equivalent to S If schedule S’ is a serial schedule, it must have T 1 before T 2

22. Chapter 922 Precedence Graph (2) P(S) = precedence graph of schedule S Nodes in P(S) are transactions If T i < s T j, put an arc T i → T j Example –S : r 1 (A); w 1 (A); r 2 (A); w 2 (A); r 1 (B); w 1 (B); r 2 (B); w 2 (B); 12 P(S) :

23. Chapter 923 Precedence Graph (3) If there is a cycle, then there is no serial schedule conflict-equivalent to S –Why? Each arc represents a requirement on the order of transactions in a conflict-equivalent serial schedule If there is no cycle (the graph is acyclic), then any topological order of the precedence graph for S suggests a conflict-equivalent schedule

24. Chapter 924 Example 9.7 S : r 2 (A); r 1 (B); w 2 (A); r 3 (A); w 1 (B); w 3 (A); r 2 (B); w 2 (B); –Look at the actions involving A : T 2 < S T 3 r 2 (A); … w 3 (A); … … w 2 (A); r 3 (A); … … w 2 (A); … w 3 (A); … –Look at the actions involving B : T 1 < S T 2 … r 1 (B); … w 2 (B); 123

25. Chapter 925 Example 9.9 S 1 : r 2 (A); r 1 (B); w 2 (A); r 2 (B); r 3 (A); w 1 (B); w 3 (A); w 2 (B); –Look at the actions involving A : T 2 < S 1 T 3 –Look at the actions involving B T 1 < S 1 T 2 : … r 1 (B); … w 2 (B); and … w 1 (B); … w 2 (B); T 2 < S 1 T 1 : … r 2 (B); … w 1 (B); 123

26. Chapter 926 Precedence Graph (3) Lemma –S 1, S 2 conflict equivalent  P(S 1 )=P(S 2 ) Proof Assume P(S 1 )  P(S 2 )   T i : T i  T j in S 1 and not in S 2  S 1 = …p i (A)... q j (A)… p i, q j S 2 = …q j (A)…p i (A)... conflict  S 1, S 2 not conflict equivalent

27. Chapter 927 Precedence Graph (4) Note: P(S 1 )=P(S 2 )  S 1, S 2 conflict equivalent Counter example –S 1 =w 1 (A) r 2 (A) w 2 (B) r 1 (B) –S 2 =r 2 (A) w 1 (A) r 1 (B) w 2 (B)

28. Chapter 928 Precedence Graph (5) Theorem –P(S 1 ) acyclic ⇔ S 1 conflict serializable Proof (  ) Assume S 1 is conflict serializable   Ss: Ss, S1 conflict equivalent  P(Ss) = P(S1)  P(S1) acyclic since P(Ss) is acyclic

29. Chapter 929 Precedence Graph (6) Proof (cont.) (  ) Assume P(S 1 ) is acyclic Transform S 1 as follows: (1) Take T 1 to be transaction with no incident arcs (2) Move all T 1 actions to the front S 1 = ……. q j (A)…….p 1 (A)….. (3) we now have S 1 = (4) repeat above steps to serialize rest!

30. Chapter 930 Precedence Graph Example (1) No cycle An equivalent serial history: T1, T2, T3, T4, T5, T6 T1 T5 T2 T3 T4 T6

31. Chapter 931 Precedence Graph Example (2) Exist cycles No equivalent serial history exists T1 T5 T2 T3 T4 T6

32. Chapter 932 Concurrency Control Techniques In practice, it is very difficult and infeasible to test for serializability of a history on the fly. Instead, follow some protocol that ensures serializability of history in which the transactions participate Concurrency control techniques –Locking –Timestamp –Multiversioning –Optimistic approach

33. Chapter 933 Locks (1) Scheduler’s job –Prevent orders of actions that lead to a nonserializable schedule Locking scheme is the most common architecture for a scheduler

34. Chapter 934 Locks (2) Requests from transactions Serializable schedule of actions Scheduler Lock table The scheduler sits between transactions and the storage system, deciding whether it is OK to forward a read or write request

35. Chapter 935 Lock Notation –l i (X) : Transaction T i requests a lock on database element X –u i (X) : Transaction T i releases its lock (“unlocks”) database element X

36. Chapter 936 Consistency (well-formed), Legal Consistency (well-formed) condition for transactions –Read or write X only when you hold a lock r i (X) or w i (X) must be preceded by some l i (X) with no intervening u i (X) –If you lock, you must eventually unlock Legal schedule –A schedule with l i (X) cannot have another l j (X) until u i (X) appears –A history is legal if it does not grant conflicting locks to two different transactions at the same time

37. Chapter 937 Example 9.10 (1) T 1 : l 1 (A); r 1 (A); A:=A+100; w 1 (A); u 1 (A); l 1 (B); r 1 (B); B:=B+100; w 1 (B); u 1 (B); T 2 : l 2 (A); r 2 (A); A:=A*2; w 2 (A); u 2 (A); l 2 (B); r 2 (B); B:=B*2; w 2 (B); u 2 (B); T 1 and T 2 are both consistent (well-formed)

38. Chapter 938 Example 9.10 (2) T 1 l 1 (A); r 1 (A); A := A+100; w 1 (A); u 1 (A); l 1 (B); r 1 (B); B := B+100; w 1 (B); u 1 (B); T 2 l 2 (A); r 2 (A); A := A*2; w 2 (A); u 2 (A); l 2 (B); r 2 (B); B := B*2 w 2 (B); u 2 (B); A 25 125 250 B 25 50 150 –A legal but not serializable schedule –“two-phase locking” is required

39. Chapter 939 Two-Phase Lock : 2PL (1) 2PL condition –In every transaction, all lock requests precede all unlock requests –Growing phase & Shrinking phase Growing phase : locks are obtained Shrinking phase : locks are relinquished If all transactions are well-formed and two- phase, then any legal history will be serializable.

40. Chapter 940 Two-Phase Lock : 2PL (2) Growing phaseShrinking phase # of locks held by T i time

41. Chapter 941 Example 9.11 (1) T 1 : l 1 (A); r 1 (A); A:=A+100; w 1 (A); l 1 (B); u 1 (A); r 1 (B); B:=B+100; w 1 (B); u 1 (B); T 2 : l 2 (A); r 2 (A); A:=A*2; w 2 (A); l 2 (B); u 2 (A); r 2 (B); B:=B*2; w 2 (B); u 2 (B); Note –Each transaction is well-formed –Each transaction is two-phase

42. Chapter 942 Example 9.11 (2) T 1 l 1 (A); r 1 (A); A := A+100; w 1 (A); l 1 (B); u 1 (A); r 1 (B); B := B+100; w 1 (B); u 1 (B); T 2 l 2 (A); r 2 (A); A := A*2; w 2 (A); l 2 (B) Denied l 2 (B); u 2 (A); r 2 (B); B := B*2; w 2 (B); u 2 (B); A 25 125 250 B 25 125 250 –Locking scheduler delays requests that would result in an illegal schedule

43. Chapter 943 Locking Protocol Rules Rule #1 : Well-formed transactions –T i : … l i (A) … p i (A) … u i (A)... Rule #2 : Legal scheduler –S = …….. l i (A) ………... u i (A) ……... Rule #3 : 2PL for transactions –T i = ……. l i (A) ………... u i (A) ……... no l j (A) no unlocks no locks

44. Chapter 944 Deadlock –Several transactions are forced by the scheduler to wait forever for a lock held by another transaction This is one problem that is inherent in locking scheme We will revisit this issue later !

45. Chapter 945 Deadlock Example T 1 l 1 (A); r 1 (A); A := A+100; w 1 (A); l 1 (B) Denied T 2 l 2 (B); r 2 (B); B := B*2 w 2 (B); l 2 (A) Denied A 25 125 B 25 50

46. Chapter 946 Shared and Exclusive Locks (1) Problem –While 2PL guarantee conflict-serializability, they do not allow two readers of DB element X at the same time –But, multiple readers is not a problem for conflict- serializability (read actions commute)

47. Chapter 947 Shared and Exclusive Locks (2) Solution : Two kinds of locks –Shared lock or read lock sl i (X) allows T i to read, but not write X It must prevent other transactions from writing X without preventing them from reading X –Exclusive lock or write lock xl i (X) allows T i to read and/or write X No other transaction may read or write X

48. Chapter 948 Shared and Exclusive Locks (3) Three requirements –Consistency of transactions –2PL of transactions –Legality of schedules

49. Chapter 949 Shared and Exclusive Locks (4) Consistency of transactions –A read action r i (X) must be preceded by sl i (X) or xl i (X), with no intervening u i (X) –A write action w i (X) must be preceded by xl i (X), with no intervening u i (X) 2PL of transactions –Locking must precede unlocking –A transaction must not have a sl i (X) or xl i (X) after any u i (Y)

50. Chapter 950 Shared and Exclusive Locks (5) Legality of schedules –No two exclusive locks If xl i (X) appears in a schedule, then there cannot be a xl j (X) until after a u i (X) appears –No exclusive and shared locks If xl i (X) appears, there can be no sl j (X) until after u i (X) appears If sl i (X) appears, there can be no wl j (X) until after u i (X) appears

51. Chapter 951 Example 9.13 Conflict-serializable schedule (T 2 < s T 1 ) –T 1 : sl 1 (A); r 1 (A); xl 1 (B); r 1 (B); w 1 (B); u 1 (A); u 1 (B); –T 2 : sl 2 (A); r 2 (B); sl 2 (B); r 2 (B); u 2 (A); u 2 (B); T 1 sl 1 (A); r 1 (A); xl 1 (B) Denied xl 1 (B); r 1 (B); w 1 (B); u 1 (A); u 1 (B); T 2 sl 2 (A); r 2 (A); sl 2 (B); r 2 (B); u 2 (A); u 2 (B);

52. Chapter 952 Compatibility Matrix Needs of compatibility matrix –When there is more than one kind of lock, the scheduler needs a rule that says, “if there is already a lock of type X on DB element Y, can I grant a lock of type S on Y?” Matrix for shared/exclusive locks SXSX SX YesNoNo Lock requested Lock held in mode

53. Chapter 953 Upgrading Locks Instead of taking an exclusive lock immediately, a transaction can take a shared lock, read, and then upgrade to exclusive so it can write Upgrading locks allows more concurrent operation

54. Chapter 954 Example 9.15 (1) Two transactions –T 1 : sl 1 (A); r 1 (A); sl 1 (B); r 1 (B); xl 1 (B); w 1 (B); u 1 (A); u 1 (B); –T 2 : sl 2 (A); r 2 (B); sl 2 (B); r 2 (B); u 2 (A); u 2 (B); Notice that T 1 takes a shared lock on B first, and later, after its calculation involving A and B is finished, requests an exclusive lock on B

55. Chapter 955 Example 9.15 (2) T 1 sl 1 (A); r 1 (A); sl 1 (B); r 1 (B); xl 1 (B) Denied xl 1 (B); r 1 (B); w 1 (B); u 1 (A); u 1 (B); T 2 sl 2 (A); r 2 (A); sl 2 (B); r 2 (B); u 2 (A); u 2 (B);

56. Chapter 956 Example 9.16 Upgrading by two transactions can cause a deadlock –If T 1 and T 2 each read DB element A and write a new value for A T 1 sl 1 (A); xl 1 (A) Denied T 2 sl 2 (A); xl 1 (A) Denied

57. Chapter 957 Update Locks (1) Update lock ul i (X) with asymmetric compatibility matrix –Only an update (not read) lock can be upgraded to a write lock –Legal schedules : read action permitted when there is either a shared or update lock –An update can be granted while there is a shared lock, but the scheduler will not grant a shared lock when there is an update

58. Chapter 958 Update Locks (2) Compatibility matrix for shared, exclusive, and update locks SXUSXU SXU YesNoYes NoNoNo Lock requested Lock held in mode

59. Chapter 959 Example 9.17 Applying update locks to example 9.16 –T 1 : ul 1 (A); r 1 (A); xl 1 (A); w 1 (A); u 1 (A); –T 2 : ul 2 (A); r 2 (A); xl 2 (A); w 2 (A); u 2 (A); T 1 ul 1 (A); r 1 (A); xl 1 (A); w 1 (A); u 1 (A); T 2 ul 2 (A) Denied ul 2 (A); r 2 (A); xl 2 (A); w 2 (A); u 2 (A);

60. Chapter 960 Increment Locks (1) Property of increment actions –If two transactions add constants to the same DB element, they commute with each other –Increment commutes with neither reading nor writing A = 5 A = 7 A = 15 A = 17 INC(A, 2) INC(A, 10) INC(A, 2)

61. Chapter 961 Increment Locks (2) Increment action, INC(A, c) –Stands for the atomic execution of the following step : “READ(A, t); t:=t+c; WRITE(A, t);” –The increment action is on a lower level than the atomicity of transactions that we support by locking Notation of increment lock and action –il i (X) : the action of T i requests an increment lock on a DB element X –inc i (X) : the action in which T i increments DB element X by some constant

62. Chapter 962 Increment Locks (3) Modification on definition of consistent transaction –A consistent transaction can only have an increment action on X if it holds an increment lock on X at the time –In a legal schedule, any number of transactions can hold an increment lock on X at any time –The action inc i (X) conflicts with both r j (X) and w j (X), for j ≠ i, but does not conflict with inc j (X)

63. Chapter 963 Increment Locks (4) Compatibility matrix for shared, exclusive, and increment locks SXISXI SXI YesNoNo NoNoNo NoNoYes Lock requested Lock held in mode

64. Chapter 964 Example 9.18 (1) –T 1 : sl 1 (A); r 1 (A); il 1 (B); inc 1 (B); u 1 (A); u 1 (B); –T 2 : sl 2 (A); r 2 (A); il 2 (B); inc 2 (B); u 2 (A); u 2 (B); –Schedule: r 1 (A); r 2 (A); inc 2 (B); inc 1 (B); T 1 sl 1 (A); r 1 (A); il 1 (B); inc 1 (B); u 1 (A); u 1 (B); T 2 sl 2 (A); r 2 (A); il 2 (B); inc 2 (B); u 2 (A); u 2 (B);

65. Chapter 965 Example 9.18 (2) –T 1 : sl 1 (A); r 1 (A); il 1 (B); inc 1 (B); u 1 (A); u 1 (B); –T 2 : sl 2 (A); r 2 (A); il 2 (B); inc 2 (B); u 2 (A); u 2 (B); –Schedule: r 1 (A); inc 1 (B); r 2 (A); inc 2 (B); T 1 sl 1 (A); r 1 (A); il 1 (B); inc 1 (B); u 1 (A); u 1 (B); T 2 sl 2 (A); r 2 (A); il 2 (B); inc 2 (B); u 2 (A); u 2 (B);

66. Chapter 966 Granularity of Locks (1) In section 9.6, the hierarchy of lockable database elements is discussed “Database element” is a purposely vague term. –Different systems use different sizes of DB elements to lock Some options –Tuples –Blocks or pages –Relations

67. Chapter 967 Granularity of Locks (2) Tradeoff of granularity –Large elements : little concurrency, easy lock management –Small elements : more concurrency, large lock table Examples –Could you have just one lockable element : the accounts relation in a bank’s database? –Would you want to lock anything smaller than a complete document in the database of documents?

68. Chapter 968 Granularity of Locks (3) A system can support multiple-granularity locks –Problem : if I lock a relation, and you lock one of its tuples, can we indulge in unserializable behavior? –Solution : think of Database elements as a hierarchy. Database composed of relations, composed of blocks, composed of tuples

69. Chapter 969 Granularity of Locks (4) Database elements organized in a hierarchy R1R1 B1B1 B2B2 B3B3 t1t1 t2t2 t3t3 Relations Blocks Tuples

70. Chapter 970 Warning (Intention) Lock (1) Ordinary lock –Shared lock (S) and exclusive lock (X) Warning lock –Notation : IS, IX, SIX Prefix ‘I’ means “intention to” –‘IS’ represents the intention to obtain a shared lock on a subelement –‘IX’ represents the intention to obtain a exclusive lock on a subelement –‘SIX’ represents both meanings of S lock and IX lock

71. Chapter 971 Warning Lock Compatibility matrix IS IX S SIX X ISIXSSIXX YesYesYesYesNo YesYesNoNoNo YesNoYesNoNo YesNoNoNoNo NoNoNoNoNo Lock requested Lock held in mode

72. Chapter 972 Warning Protocol (1) Warning protocol: rules for managing locks on a hierarchy of database elements –Start at the root of the hierarchy –If you want to read/write an element, put a lock on it –If you want to read/write a subelement, put a warning lock on it, and proceed to the appropriate child or children Locking rule –You cannot put a lock where someone else has a warning, but you can also put a warning

73. Chapter 973 Warning protocol (2) Remember –Acquire locks from root to leaf –Release locks from leaf to root

74. Chapter 974 Example 9.21 (1) Movie(title, year, length, studioName) T 1 –SELECT * FROM Movie WHERE title = ‘King Kong’; T 2 –UPDATE Movie SET year = 1939 WHERE title = ‘Gone With the Wind’;

75. Chapter 975 Example 9.21 (2) Movies King Kong T 1 (IS) King Kong Gone With the Wind T 1 (S) T 2 (IX) T 2 (X)

76. Chapter 976 Phantom (1) (Example 9.22) Transaction T 3 : –SELECT SUM(length) FROM Movies WHERE studioName = ‘Disney’; T 3 get a IS lock on ‘Movies’ relation and S locks on all tuples for Disney movies At the same time, transaction T 4 insert a new Disney movie into a block T 3 did not get a lock

77. Chapter 977 Phantom (2) Phantom tuple –The tuple that should have been locked but wasn’t, because it did not exist at the time the locks were taken Solution –Actions of DB modification - insertion or deletion – should be treated as write actions on the relation as a whole –In example 9.22, T 4 must obtain an X lock on the relation ‘Movies’

78. Chapter 978 Motivation for Tree-Based Locking (1) 2PL is a disaster for something like a B-tree index –Every transaction using B-tree index would have to lock the root (at least) –That transaction cannot unlock the root until it has acquired all the locks it needs because of 2PL –So only one such transaction at a time could operate –Remember that any insertion or deletion might wind up rewriting the root

79. Chapter 979 Motivation for Tree-Based Locking (2) Most of time, we can tell immediately that a node will not have to be rewritten Example –We are doing an insert, and the child of the root that we visit is not full –In a delete action, the child of the root we visit has more has more than the minimum number of keys and pointers

80. Chapter 980 Motivation for Tree-Based Locking (3) Releasing the lock on the root early will violate 2PL, so we cannot be sure that the schedule will be serializable Solution –A specialized protocol for transactions that access tree-structured data like B-trees A specialized protocol violate 2PL, but uses the fact that accesses to elements must proceed down the tree to assure serializability

81. Chapter 981 Rules for Locking Tree Nodes (1) Assumption –There is only one kind of lock, l i (X) Note that the idea generalizes to any set of lock modes –Transactions are consistent –Schedules must be legal –There is no 2PL requirement on transactions

82. Chapter 982 Rules for Locking Tree Nodes (2) Start by locking any node –B-tree application always starts at root node Subsequent nodes can only be locked if you have a lock on its parent Nodes may be unlocked at any time A transaction may not relock a node on which it has released a lock, even if it still holds a lock on the node’s parent

83. Chapter 983 Example 9.23 (1) A tree of lockable elements A BC DE FG

84. Chapter 984 Example 9.23 (2) T 1 l 1 (A); r 1 (A); l 1 (B); r 1 (B); l 1 (C); r 1 (C); w 1 (A); u 1 (A); l 1 (D); r 1 (D); w 1 (B); u 1 (B); w 1 (D); u 1 (D); w 1 (C); u 1 (C); T 2 l 2 (B); r 2 (B); l 2 (E) Denied T 3 l 3 (E); r 3 (E);

85. Chapter 985 Example 9.23 (3) T 1 T 2 …… l 2 (E); r 2 (E); w 2 (B); u 2 (B); w 2 (E); u 2 (E); T 3 …… l 3 (F); r 3 (F); w 3 (F); u 3 (F); l 3 (G); r 3 (G); w 3 (E); u 3 (E); w 3 (G); u 3 (G);

86. Chapter 986 Why the Tree Protocol Works? If all transactions start at the root, as for B- tree, then no transaction can pass another going down the tree –Because a transaction must hold at least one lock until it is finished locking Even if transactions start at non-roots, they can never pass each other –Formally, if the highest node that T 1 and T 2 lock in common is X, and T 1 locks X first, then every node that they lock in common will be locked first by T 1

87. Chapter 987 Example 9.24 (1) Precedence graph derived from the schedule of example 9.23 –T 1 and T 2 lock B in common, and T 1 locks it first T 1 < S T 2 –T 2 and T 3 lock E in common, and T 3 locks it first T 3 < S T 2 –T 1 and T 3 lock no node in common 1 3 2

88. Chapter 988 Example 9.24 (2) In the precedence graph, we claim that any topological order of the transactions is an equivalent serial schedule –(T 1, T 3, T 2 ), (T 3, T 1, T 2 ) Because all nodes in such a serial schedule are touched in the same order as they are in the original schedule

89. Chapter 989 Example 9.25 (1) There are ten transactions T 1, T 2 and T 3 lock the root in that order There are two children of the root –The first locked by T 1 through T 7 –The second locked by T 2, T 3, T 8, T 9 and T 10 Serial order –1 st subtree : (T 4, T 1, T 5, T 2, T 6, T 3, T 7 ) –2 nd subtree : (T 8, T 2, T 9, T 10, T 3 ) One of the serial orders of the all transactions –(T 4, T 8, T 1, T 5, T 2, T 9, T 6, T 10, T 3, T 7 )

90. Chapter 990 Example 9.25 (2) 415 8910 6 3 7 2

91. Chapter 991 Simple Scheduler (1) The scheduler inserts lock actions into the stream of reads, writes, and other actions that access data –Transactions themselves do not request locks The scheduler releases the locks when the transaction manager tells it that the transaction will commit or abort –Transactions do not release locks

92. Chapter 992 Simple Scheduler (2) lock table Scheduler, Part I Scheduler, Part II From transactions READ(A); WRITE(B); COMMIT(T); …… LOCK(A); READ(A); …… READ(A); WRITE(A); ……

93. Chapter 993 Simple Scheduler (3) Part I –Inserts appropriate lock actions ahead of all database-access operation, such as read, write, increment, or update –Issues unlocks to lock table after transaction commit or abort –If any transactions are waiting for any of these locks, Part I notifies Part II

94. Chapter 994 Simple Scheduler (4) Part II –Take care of the sequence of lock and database access actions –For a database access, it is transmitted to the database and executed –For a lock action, determine if the lock can be granted –When Part II is notified that a lock is available, it determines the next transactions that can be granted

95. Chapter 995 Example 9.19 Transactions –T 1 : r 1 (A); r 1 (B); w 1 (B); –T 2 : r 2 (A); r 2 (B); S : r 1 (A); r 2 (A); r 2 (B); r 1 (B); w 1 (B); –r 1 (A);  sl 1 (A); r 1 (A); –r 2 (A); r 2 (B);  sl 2 (A); r 1 (A); sl 2 (B); r 2 (B); –r 1 (B);  ul 2 (B); r 1 (B); // WHY and HOW –w 1 (B);  xl 2 (B); w 1 (B); // After T 2 commits

96. Chapter 996 Lock Table A lock table is a mapping from database elements to their lock information Table is implemented with a hash table –Hash Key : (addresses of ) database element DB element A Lock information for A

97. Chapter 997 Structure of Lock Table Entries (1) A Group mode : U Waiting : yes List : Tran Mode Wait? Tnext Next T1T1 Sno T2T2 U T3T3 Xyes Element Info

98. Chapter 998 Structure of Lock Table Entries (2) Group mode –A summary of the most stringent conditions that a transaction requesting a new lock on A faces –Purpose to simplify the grant/deny decision by comparing the request with only the group mode –Example with S/X/U lock modes S: only shared locks are held U: one update lock and perhaps one or more shared locks X: one exclusive lock and no other locks

99. Chapter 999 Structure of Lock Table Entries (3) Waiting bit –Tells that there is at least one transaction waiting for a lock on A List entry’s structure –Tran : the name of the transaction holding or waiting for a lock –Mode : the mode of this lock –Wait? : whether the transaction is holding or waiting for the lock –Tnext : links all entries for a particular transaction –Next : links the entries themselves

100. Chapter 9100 Lock Logic (1) Transaction T requests a lock on A Is there a lock table entry for A ? Is group mode compatible with request ? Entry is created Wait? = ‘yes’ Entry is created Lock is granted Entry is created Lock is granted No Yes No Yes

101. Chapter 9101 Lock Logic (2) Do we need to see if there are blocked transactions before consulting the group mode ??? (THINK ABOUT IT) Lock conversion issue

102. Chapter 9102 Unlock Logic (1) Transaction T unlocks A Are there waiting transactions ? Grant one or more locks from the list of requesting locks Adjust group mode There is nothing to do Yes No Delete the T entry on the list

103. Chapter 9103 Unlock Logic (2) Approaches to grant locks from the list of requested locks (waiting transactions) –First-come-first-served Grant the lock request that has been waiting the longest Advantage: no starvation –Priority to shared locks Grant locks in sequence of all shared locks, all update locks and exclusive locks Disadvantage: possibility of starvation –Priority to upgrading First grant X lock upgrading from U lock