1. CONCURRENCY CONTROL Spring 2015

2. Warning This is a first draft I welcome your corrections

3. One common objective Maintaining database in a consistent state  Means here maintaining the integrity of the data After a money transfer between two accounts, the amount debited from the fist account should be equal to the amount credited to the second account  Assuming no-fee transfer

4. Two different problems Handling outcomes of system failures:  Server crashes, power failures, …  Previous chapter Preventing inconsistencies resulting from concurrent queries/updates that interfere with each other  This chapter

5. The problem Assume that we want to process in parallel  A transaction T 1 crediting a checking account by $2,000  A transaction T 2 debiting the same account by $100

6. A correct schedule T 1 reads the current balance ($500) T 1 computes the new balance ($2,500) T 1 writes the new balance ($2,500) to disk T 2 reads the current balance ($2,500) T 2 computes the new balance ($2,400) T 2 writes the new balance ($2,400) to disk Serial execution of the two transactions

7. Another correct schedule T 2 reads the current balance ($500) T 2 computes the new balance ($400) T 2 writes the new balance ($400) to disk T 1 reads the current balance ($400) T 1 computes the new balance ($2,400) T 1 writes the new balance ($2,400) to disk Another serial execution

8. An incorrect schedule T 1 reads the current balance ($500) T 2 reads the current balance ($500) T 1 computes the new balance ($2,500) T 1 writes the new balance ($2,500) to disk T 2 computes the new balance ($400) T 2 writes the new balance ($400) to disk That's not right!

9. Another problem Assume that we want to process in parallel  A transaction T 1 crediting a checking account X by $2,000  A transaction T 2 debiting a checking account Y by $100

10. A correct schedule T 1 reads the current balance of X ($500) T 1 computes the new balance of X ($2,500) T 1 writes the new balance of X ($2,500) to disk T 2 reads the current balance of Y ($800) T 2 computes the new balance of Y ($700) T 2 writes the new balance of Y ($700) to disk Serial execution of the two transactions

11. Another correct schedule T 1 reads the current balance of X ($500) T 2 reads the current balance of Y ($800) T 1 computes the new balance of X ($2,500) T 1 writes the new balance of X ($2,500) to disk T 2 computes the new balance of Y ($700) T 2 writes the new balance of Y ($700) to disk A correct concurrent schedule

12. Two different approaches (I) Most OS ensure the correctness of conflicting operations by forcing them to execute in mutual exclusion  Through locks, semaphores, monitors Avoid conflicts but forces operations to execute in some serial order  Acceptable for short critical sections  Not acceptable for DB Would slow down update rate

13. Two different approaches (II) DBMS will  let potentially conflicting transactions execute concurrently  controlt heir actual schedule and guarantee that their outcome will be identical to some serial execution of these transactions Serializability criterion

14. Notations As far as concurrency control is concerned, a transaction can be represented by the sequence of its read and write operations:  r 1 (A); w 1 (A) means transaction T 1 reads A then updates A A transaction schedule S represents the sequence of the read/write operations of multiple transactions as they are executed  r 1 (A); r 2 (A); w 1 (A); w 2 (B)

15. Serial schedules A schedule is said to be serial if all its transactions execute  One at a time  Without any interleaving All serial schedules are assumed to be correct Different orders of execution may produce different outcomes

16. Example Transaction T 1 reads the balance of an account Transaction T 2 withdraws $200 Two serial schedules  S = r 1 (A); r 2 (A); w 2 (A)  S' = r 2 (A); w 2 (A); r 1 (A) are both correct even though T 1 will return different values

17. Serializable schedules An interleaved schedule is said to be serializable if its outcome is identical to some serial schedule for the same transactions All serializable schedules are assumed to be correct

18. Example Transaction T 1 reads the balance of an account Transaction T 2 withdraws $200 S = r 1 (A); r 2 (A); w 2 (A) is a serial schedule S' = r 2 (A); r 1 (A); w 2 (A) is interleaved but equivalent to S  S' is serializable

19. Defining equivalence We cannot depend on either  The original values of the DB elements being modified  Their new values We will use conflict-based serializability:

20. Conflicting operations Two operations are said to be conflicting if  They belong to two different transactions T 1 and T 2  They access the same DB element A  At least one of them is a write

21. Examples The following pairs of operations conflict:  r 1 (A); w 2 (A)  w 1 (A); r 2 (A)  w 1 (A); w 2 (A) The following pairs do not:  r 1 (A); r 2 (A)  w 1 (A); r 2 (B)  w 1 (A); w 2 (B)

22. Important property Changing the order of two conflicting operations is likely to affect the correctness of the schedule  r 1 (A); r 2 (A); w 1 (A); w 2 (A) is not equivalent to r 1 (A); w 1 (A) r 2 (A); w 2 (A) Changing the order of two non-conflicting operations will never affect the correctness of the schedule  r 2 (A); r 1 (A); w 2 (A) is equivalent to r 1 (A); r 2 (A); w 2 (A)

23. Our serializability criterion Two schedules S 1 and S 2 are said to be conflict equivalent if S 1 can be transformed into S 2 by a series of swaps on non-conflicting actions.  G.-M. A schedule S is said to be conflict serializable if it is conflict-equivalent to some serial schedule.  G.-M.

24. Example r 2 (A); r 1 (B); w 2 (A); r 3 (A); w 1 (B); w 3 (A); r 2 (B); w 2 (B) can be successively transformed into r 1 (B); r 2 (A); w 2 (A); w 1 (B); r 3 (A); r 2 (B); w 3 (A);w 2 (B) r 1 (B); r 2 (A); w 1 (B); w 2 (A); r 2 (B); r 3 (A); w 2 (B); w 3 (A) r 1 (B); w 1 (B); r 2 (A); w 2 (A); r 2 (B); w 2 (B); r 3 (A); w 3 (A) which corresponds to a serial execution of the transactions T 1, T 2 and T 3

25. Another example The schedule r 1 (A) r 2 (A) w 1 (A) w 2 (A) cannot be transformed into either r 1 (A) w 1 (A) r 1 (A) w 1 (A) or r 1 (A) w 1 (A) r 2 (A) w 2 (A) and is not conflict serializable

26. Definition For a given schedule S, a transaction T 1 is said to be ahead of a transaction T 2 if there is an action A 1 in T 1 and an action A 2 such that  A 1 appears ahead of A 2 in the schedule,  Both A 1 and A 2 access the same element X of the DB  At least one of them is a write We write T 1 < S T 2

27. Precedence graph The precedence graph for a schedule S contains:  A node for each transaction T i in S  An arc from node T i to node T k if T i < S T k

28. Example In the schedule r 2 (A); r 1 (B); w 2 (A); r 3 (A); w 1 (B); w 3 (A); r 2 (B); w 2 (B) we have  T 1 < S T 2 because w 1 (B); …; r 2 (B);  T 2 < S T 3 because w 2 (A); …; r 3 (A); 123

29. Another example In the schedule r 1 (A) r 2 (A) w 1 (A) w 2 (A) we have  T 2 < S T 1  T 1 < S T 2 12

30. Theorem The necessary and sufficient condition for a schedule to be conflict-serializable is that its precedence graph has no cycles

31. Necessary condition If schedule S contains a cycle, such as T 1  T 2  T 3  …  T n  T 1, any equivalent serial schedule must have  All actions of T 1 preceding all actions of T 2,  All actions of T 2 preceding all actions of T 3  …  All actions of T n preceding all actions of T 1, which is impossible

32. Sufficient condition Proof by induction Basis:  Obvious if the schedule contains a single transaction

33. Sufficient condition Induction step:  Assume it is true for any schedule with n - 1 transactions  Let S be a schedule with n transactions  Since the precedence graph of S has no cycles, at least one of its nodes has no incoming arcs  Take all actions of transaction associated with that node and start new schedule with them  What remains of S has no cycles and n - 1 transactions

34. Pessimistic Concurrency Control

35. Pessimistic scheduling (I) Uses locks Incoming transactions Lock table Transaction scheduler Serializable transaction schedule

36. Pessimistic scheduling (II) Scheduler will guarantee the serializability of the schedules it issues by enforcing sufficient conditions These conditions will be enforced through locking Outcome will be schedules that satisfy conflict serializability

37. Locking Two operations  l i (A): transaction T i requests and gets an exclusive lock on element A  u i (A): transaction T i releases its exclusive lock on element A

38. First rule: Well-formed transactions A transaction T can only access an element A of a DB if it has obtained a lock for A and not released it All transactions will eventually release all their locks T i : … l i (A) … r i (A) …w i (A) … u i (A)...

39. Second rule: Legal scheduler Scheduler will not grant a lock to a transaction T k for a DB entity A if another transaction T i holds a lock on A T i : … l i (A) … r i (A) …w i (A) … u i (A)... l k (A) must wait x

40. Locking is not enough First transaction: l 1 (A) r 1 (A) u 1 (A) … … … l 1 (A) w 1 (A) u 1 (A) Second transaction: l 2 (A) r 2 (A) u 2 (A) … l 2 (A) w 2 (A) u 2 (A) T 1 and T 2 read same old value of A then enter a race condition when they update it

41. Two-phase locking Requires all transactions to acquire all their locks before they release any Go through two phases  Acquiring their locks  Releasing them Locks owned by transaction Time

42. Claim: 2PL produces serializable schedules Geometric argument: Locks owned by T 1 Time Locks owned by T 2

43. More formally Any legal schedule that only contains consistent two-phase locked transactions is serializable  To prove it we will show we can convert S = T 1, T 2,..., T n into an equivalent serial schedule S'

44. Proof (I) Basis:  True for n = 1 Induction step:  Let T i be transaction with first unlock action, say u i (X), in entire schedule  One way to start constructing S' would be to move all actions of T i ahead of the actions of all other transactions

45. Proof  Consider an arbitrary action of T i, say w i (Y)  The sole condition that would prevent us from moving w i (Y) to the beginning of S' would the existence of a conflicting operation w k (Y) in some transaction T k  This would assume the existence in the schedule of a sequence of action containing l k (Y)...w k (Y)... U k (Y)... l i (Y)...w i (Y)...u i (Y)... which is contrary to our assumption.

46. 2PL is enough First transaction: l 1 (A) r 1 (A) … w 1 (A) u 1 (A) Second transaction: l 2 (A) r 2 (A) … w 2 (A) u 2 (A) T 2 must now wait Schedule is serial and thus serializable

47. Shared and exclusive locks Shared locks:  sl i (A) allows transaction T i to access element A in read-only mode  Can be shared with other transactions requiring the same mode of access Exclusive locks:  xl i (A) grants to transaction T i the exclusive right to access element A Required for write access

48. First rule: Well-formed transactions A transaction T can only  Perform a read action r i (A) on an element A of a DB if it has obtained a shared or an exclusive lock for A and not released it  Perform a write action w i (A) on an element A of a DB if it has obtained an exclusive lock for A and not released it All transactions will eventually release all their locks

49. Second rule: Legal scheduler Scheduler will not grant:  A shared lock to a transaction T k for a DB entity A if another transaction T i holds a exclusive lock on A  An exclusive lock to a transaction T k for a DB entity A if another transaction T i holds a a lock on A (either shared or exclusive)

50. Third rule: Two-phase locking Requires all transactions to acquire all their locks before they release any The option of downgrading a lock and go from an exclusive lock xl i (A) to a shared lock sl i (A) is not offered

51. Interesting property A transaction T i holding a shared lock sl i (A) on an element A knows that the value of this element will not change as long as it holds that lock

52. Compatibility matrix Lock requested  Lock grantedSX SYesNo X

53. First transaction: sl 1 (A) r 1 (A) … xl 1 (A) w 1 (A) u 1 (A) Next problem: Deadlocks Both denied Second transaction: sl 2 (A) r 2 (A) … xl 2 (A) w 2 (A) u 2 (A)

54. Two solutions (I) All or nothing lock allocation  A transaction will either get all the locks it needs or none of them  Deadlock free  Limits concurrency Locksacquiredby T 1

55. Two solutions (II) Abort one of the transactions involved in a deadlock  Will undo all its actions  Just as if transaction did not happen  Will not appear on the schedule

56. Update locks Useful when a transaction wants to read an element A and reserve the right to update it later  ul i (A) Can be granted if another transaction T k has a shared lock sl k (A) on DB element A Once granted prevents any other transaction T k to obtain any lock on DB element A

57. Update locks (II) Main advantage is reducing deadlocks  Requires preventing transactions from upgrading their shared locks.

58. Compatibility matrix A transaction can get an update lock for an entity for which another transaction has a shared lock but the reverse is not true Lock requested  Lock granted SUX SYes No U X

59. We avoid a deadlock First transaction: ul 1 (A) r 1 (A) xl 1 (A) w 1 (A) u 1 (A) Second transaction: ul 2 (A) r 2 (A) xl 2 (A) w 2 (A) u 2 (A) T 2 must now wait Schedule is serial and thus serializable

60. Increment locks Most DB updates involve adding or subtracting some quantity to a value in the DB  Debit/credit operations  Updating inventory New INC i ( A, increment) "locks"  Consist of an atomic sequence of : READ(A,t) t = t + increment WRITE(A, t) OUTPUT(A);

61. Properties Increment locks  Commute among themselves  Are incompatible with any other locks

62. Locking schedulers Cannot trust transactions to lock/release resources Must be done by the scheduler  Two-step scheduler First step is to add lock requests to transactions Second step is to produce and execute a legal schedule

63. A two-step scheduler Scheduler step I Scheduler step II DB Lock table Lock table Transactions Transactions + locks Legal schedule

64. Inserting locks (I) Simple case:  One type of locks  Just add a lock request before any attempt to access a DB element that is not already locked by the transaction

65. Inserting locks (II) General case:  Multiple locks S/X or S/X/U  Just add the appropriate lock request before any attempt to access a DB element that is not already locked by the transaction S if transaction will not modify the element X if transaction will modify the element U if transaction could modify the element

66. Inserting locks (III)  Lock manager must look ahead to find out whether the transaction will/will not modify a given entity Easy for interactive SQL requests Harder for embedded SQL  Must know the logic of the program

67. The lock table Hash table:  Each entry contains all information for a given element A Organized as a linked list Element A lock status

68. A lock table entry Object: A Max mode: U Waiting: Y Trans. list: Object: A Max mode: U Waiting: Y Trans. list: T1T1 T1T1 S S no T2T2 T2T2 U U T3T3 T3T3XX yes Trans. Lock W? Next TLink In our example. the highest lock is the update lock held by T 2

69. Explanations (I) Header contains  Element identifier A  Highest lock held on A (for faster decisions)  Flag telling whether there are transactions that wait for the lock (Y/N)  Link to list of all transactions that Have requested a log on A Hold a lock on A

70. Explanations (II) Each transaction entry in the linked list contains  Transaction identifier  Lock obtained/requested by transaction  Flag telling whether the transactions is (Y/N)  Link to next transaction waiting for a lock/holding a lock on element A  Link to other lock entries for the transaction Simplifies unlocks at the end of the transaction

71. Handling lock requests Assume transaction T requests a lock on entity A  If A has no lock entry A lock entry is created, the lock is granted and a transaction entry for T is created  Else if the request is compatible with the highest lock already granted on A The lock is granted and a transaction entry for T is created  Else T is put on the wait list, the wait flag is set to Yes and a transaction entry for T is created.

72. Handling lock releases Delete first the transaction entry for the transaction that released its lock Update the lock status If wait flag is Yes  Grant one or more locks to the transactions that were waiting  We can give priority to the transactions that Waited the longest (First-come-first-served) Request shared locks Request upgrade locks

73. Locks with multiple granularity Want to be able to grant locks at different levels of the database  Whole relation Block containing several tuple Single tuple Very attractive for read-only transactions

74. The DB hierarchy Database Relation … Block … … …Tuple … … … Block… …Tuple …

75. Warning locks (I) Handling locks at multiple levels create a problem  Cannot grant a shared lock on a relation if another transaction has an exclusive lock on one of the blocks or the tuples in that relation  Cannot grant an exclusive lock on a block if another transaction has any lock on one of tuples in that block

76. The problem Handling locks at multiple levels create a problem  Cannot grant a shared lock on a relation if another transaction has an exclusive lock on one of the blocks or the tuples in that relation  Cannot grant an exclusive lock on a block if another transaction has any lock on one of tuples in that block

77. Warning locks Exist at the block or the relation level Warn that another transaction has a lock on some sub entity of the relation or the block Two types  IS warns that that another transaction has a shared lock on some sub entity  IX warns that that another transaction has an exclusive lock on some sub entity

78. Compatibility issues (I) Cannot grant an exclusive lock on a relation/block if that entity already has an warning lock (either IS or IX) Cannot grant a shared lock on a relation/block if that entity already has an exclusive warning lock (IX only)

79. Compatibility issues (II) Cannot grant an exclusive warning lock on a relation/block if that entity already has any lock (either S or X) Cannot grant a shared warning lock on a relation/block if that entity already has an exclusive lock (X only) Intention locks never interfere with each other

80. Compatibility matrix Lock requested  Lock granted ISIXSX ISYes No IXYes No SYesNo X

81. Tuple Example Database Relation R IX Block ISBlock S Tuple X Relation S IS Tuple Block ISBlock Tuple STuple

82. Handling deletions/insertions (I) Problems when transactions create sub elements of a locked element:  Relation R contains customers' checking accounts for a bank  Transaction T has a read lock on the whole relation to compute the total values of all checking accounts  Transaction U creates a new account Not guaranteed to appear in result of transaction T

83. Handling deletions/insertions (II) These missing accounts are called phantom accounts Similar problem when accounts are deleted  Deleted account could appear in result of transaction T Solution is to require insertions and deletions to acquire an exclusive lock on the whole relation

84. Tree-based locking Assume we want to access a relation that is indexed by a B+-tree Will have to lock the tree while searching it Locked

85. The problem Two-phase locking prevents transactions from releasing any lock while we are still acquiring new ones  Cannot release lock on root of tree until they have acquired all their locks  Tree root will remain locked for too long  Prevent other transactions from accessing the relation through the index

86. The solution (I) Start with any node X (root in the example) Z Y X is locked

87. The solution (II) Can now lock any child of X Z Y is locked X is locked

88. The solution (III) Can release lock on X as soon as we know we will never modify X Z Y is locked

89. The solution (IV) Can now lock any child of Y X Z is locked Y is locked

90. The solution (V) Can release lock on Y as soon as we know we will never modify Y X Z is locked Y

91. A problem Can transaction T get a new lock for X (or Y)? X Z is locked Y

92. Answer NO, another transaction could have acquired a lock on a subtree of X after T released the lock X Z is locked Y W is locked by another transaction that followed T

93. Rules 1.First lock by transaction T may be on any item 2.After that, T can lock any item Q if and only it holds a lock on parent(Q) 3.Any item may be unlocked at any time 4.T cannot relock any item Q on which it has released a lock even if it holds a lock on parent(Q)

94. Replacing two-phase locking Third rule violates two-phase locking  It allows transactions to release locks on tree nodes  Only prevents them for reacquiring a lock

95. Correctness proof SKIPPED NOT ON THE QUIZ

96. Optimistic Concurrency Control

97. Example Pessimistic concurrency control  Assumes that serializability must be enforced  Prevent the occurrence of non serializable schedules through locking Optimistic concurrency control  Assumes that most transactions will cause no serializability conflicts  Detect and abort offending transactions

98. Advantages and disadvantages Optimistic concurrency control  Works very well when conflicts are infrequent Avoids locking overhead Aborts few transactions  Works less well when conflicts more frequent Preventing becomes then cheaper than undoing

99. An analogy Should we put traffic lights at each intersection?  Would prevent collisions  Would create delays for motorists Cities use multiple approaches  Nothing  Stop signs  Traffic lights  Overpasses and underpasses

100. Timestamps

101. How it works (I) Attach to each incoming transaction a unique sequential timestamp  Proxy for the order of the transaction in an equivalent serial schedule  Time stamp can be generated By the system clock  If clock ticks are frequent enough By a counter inside the scheduler  Logical clock

102. How it works (II) Attach to each element X of DB two timestamps and a commit bit  RT(X): timestamp of last transaction that read X  WT(X): timestamp of last transaction that updated X  C(X): 1 if last transaction that updated X has committed and 0 otherwise

103. How it works (III) Monitor all read/update operations by transactions and verify that they correspond to a physically realizable serial schedule  T 4 reads X and finds RT(X) = 3 then updates it and finds RT(X) = 4 and WT(X) = 3 Very nice as long as X is committed  T 5 reads X and finds RT(X) = 4 then wants to update it but finds WT(X) = 6 T 6 cannot happen before T 5

104. How it works (IV)  T 7 reads X and finds RT(X) = 5 then try to update it and finds RT(X) = 8 and WT(X) = 3 to T 8 cannot happen before T 7

105. An old problem revisited Assume that we want to process in parallel  A transaction T 1 crediting a checking account A by $2,000  A transaction T 2 debiting the same account A by $100 Initial properties of account are  balance is $500  RT(A) = WT(A) = 0  C(A) = 1

106. A correct schedule T 1 reads the current balance ($500)  RT(A) goes from 0 to 1, WT(A) = 0, T 1 writes the new balance ($2,500) to disk  RT(A) =1, WT(A) goes from 0 to 1, C(A) goes from 1 to 0 T 1 commits  C(A) goes back to 1 T 2 reads the current balance ($2,500)  RT(A) goes from 1 to 2, WT(A) = 1 T 2 writes the new balance ($2,400) to disk  RT(A) = 2, WT(A) goes from 1 to 2, C(A) goes from 1 to 0

107. An incorrect schedule T 1 reads the current balance ($500)  RT(A) goes from 0 to 1, WT(A) = 0, T 2 reads the current balance ($500)  RT(A) goes from 1 to 2, WT(A) = 0 T 1 tries to write the new balance ($2,500) to disk  Cannot do it because RT(A) = 2  Will ABORT T 1 and restart it as T 3

108. Another incorrect schedule T 2 reads the current balance ($500)  RT(A) goes from 0 to 2, WT(A) = 0 T 2 writes the new balance ($2,400) to disk  RT(A) = 2, WT(A) goes from 0 to 2, C(A) goes from 1 to 0 T 2 commits  C(A) goes back to 1 T 1 tries to read the current balance ($500)  Cannot do it because WT(A) = 2  T 2 cannot happen before T 1

109. A last problem T 1 reads the current balance ($500)  RT(A) goes from 0 to 1, WT(A) = 0, T 1 writes the new balance ($2,500) to disk  RT(A) =1, WT(A) goes from 0 to 1, C(A) goes from 1 to 0 T 2 tries to read the current balance ($2,500)  Cannot do it now  Must wait until T 1 commits and C(A) = 1

110. The rules When scheduler processes a request from a transaction T, it can  Grant the request  Abort T and restart it with a new timestamp Rollback  Delay T and later decide to either grant the request or abort and restart the transaction

111. The rules for read requests When scheduler receives r T (A) for element X  If TS(T) ≥ WT(X) and C(X) = 1 It grants the request New value of RT(X) is max(TS(T), RT(X))  If TS(T) ≥ WT(X) and C(X) = 0 It delays the request  If TS(T) < WT(X) and C(X) = 0 It rolls back the request  Current schedule is not serializable

112. The rules for write requests When scheduler receives w T (A) for element X  If TS(T) ≥ RT(X) and TS(T) ≥ WT(X) It grants the request Will set WT(X) to TS(T) and C(T) to 0  If TS(T) ≥ RT(X) but TS(T) ≥ WT(X) and C(X) = 1 It cancels the request and let the transaction proceed The write was overwritten  If TS(T) ≥ RT(X) but TS(T) ≥ WT(X) and C(X) = 0 It delays the request  If TS(T) < RT(X) It rolls back the request

113. Explanation If TS(T) ≥ RT(X) but TS(T) ≥ WT(X) and C(X) = 1  A more recent transaction has overwritten X  We have a write conflict between the two transactions  We solve it by doing nothing  Same outcome as having done the write beforehand and having the value overwrittenby the more recent transaction

114. Multiversion timestamps DB maintain old versions of the DB  In reality, just some old blocks with their old timestamps Old transactions that have been delayed can read these old values when TS(T) < WT(X) as long as TS(T) ≥ WT(X old )

115. New rules When a new write w T (X) occurs, we create a new version of X, X t with t = TS(T) When a read r T (X) occurs the scheduler finds the version X t of X such that  t ≤ TS(T)  There is no version X t' such that t < t' ≤ TS(T) Write times are associated with versions and never change Think of immutable files Here versions are immutable

116. New rules Read times are also associated with versions  Will be used to reject writes whose time is less than the read times of previous versions When a version X t has a timestamp t such that no active transaction has a timestamp TS(T) lower than t, we can delete all versions of X with timestamps lower than t

117. Combining locks and timestamps Several commercial DBMSs combine locks and timestamps:  Red/write transactions use two-phase locking To minimize the number of aborted transactions  Read-only transactions use multiversion timestamping Will never be aborted

118. Concurrency control through validation

119. Key idea Let transaction proceed but without writing anything even to I/O buffers Decide whether the transaction could have happened with all reads and writes equivalent to those that would all have taken place exactly at the same time  If yes commit the transaction and update the database  If no, rollback

120. The three phases of a transaction Read:  Transaction T reads from DB all he entities in its read set and computes in its private address space the results it needs to write Validate:  Scheduler compares the read and write sets of T with those of of other transactions and decides either to commit it or to rollback it Write:  T updates the DB

121. Data structures (I) For each transaction "of interest" T  RS(T): the read set of T  WS(T): the write set of T  START(T): the time at which T has started  VAL(T): the time at which T was validated  FIN(T): the time at which T has completed all its updates to the DB

122. Data structures (II) At the global level  START, the set of transactions that have started but have not yet validated  VAL, the set of transactions that have been validated but have not yet finished updating the DB  FIN, the set of transactions that have completed all their updates to the DB

123. Data structures (III) Transactions get automatically removed  From the START set when they get validated  From the valid set when they finish all their DB updates Can remove a transaction T from FIN as soon as FIN(T) < START(U) for all active transactions U

124. First validation rule Must rollback transactions that have read potentially stale data  Could have been modified by another transaction after the read Say there is a transaction U such that  RS(T)  WS(U)   FIN(U) > START(T)

125. Second validation rule Must rollback transactions that will write something that could be overwritten by an "earlier" transaction Say there is a transaction U such that  WS(T)  WS(U)   FIN(U) > START(T)

126. Example T1 starts, reads element X then computes a new value for X T2 starts, reads same element T1 validates Cannot validate T2

127. Example T1 starts, reads element X then computes a new value for X T1 validates T2 starts T1 finishes T2 reads X Cannot validate T2 because we do not know when the read took place

128. Example T1 starts, reads element X then computes a new value for X T1 validates T1 finishes T2 starts, reads same element X Can validate T2

129. Example T1 starts, reads element X then computes a new value for X T1 validates T2 starts, computes a new value for X Can validate T2 because it could be overwritten

130. Example T1 starts, reads element X then computes a new value for X T1 validates T2 starts T1 finishes T2 computes a new value for X Cannot validate T2 because we do not know the timing of the write

131. Example T1 starts, reads element X then computes a new value for X T1 validates T1 finishes T2 starts, computes a new value for X Can validate T2