1. Distributed Processing Systems ( Concurrency Control ) 오 상 규 서강대학교 정보통신 대학원 Email : sgoh@macroimpact.com Email : sgoh@macroimpact.com

2. Concurrency Control 서강대학교 정보통신 대학원 Transaction Definition : a series of actions, carried out by a single user/application program, which must be treated as an individual unit. ACID Properties 3 Atomicity : A transaction must be all-or-nothing. 3 Consistency : A transaction takes the system from one consistent state to another consistent. 3 Isolation : Although multiple transactions may execute concurrently, each transaction must be unaware of other transactions. 3 Durability : After a transaction completes successfully, the changes it has made to database persist, even if there are system failures.

3. Concurrency Control 서강대학교 정보통신 대학원 State Transition in the Transaction Failed Active Committed Partially committed Aborted Active : the initial state, transaction stays in this state while it is executing. Partially Committed : after the final statement has been executed. Committed : after successful completion. Failed : after the discovery that normal execution can no longer proceed. Aborted : after the transaction has been rolled back, the database restored to its state prior to the start of the transaction.

4. Concurrency Control 서강대학교 정보통신 대학원 Need for Synchronization (Lost Update) $204B.Write(balance+4) $203B.Write(balance+3) $200balance := B.Read( ) $200balance := B.Read( ) $297C.Write(balance - 3) $300balance := C.Read( ) $96A.Write(balance-4) $100balance := A.Read( ) Bank$Deposit(B,3)Bank$Deposit(B,4) Bank$Withdraw(C,3)Bank$Withdraw(A,4) Transaction U :Transaction T : 3 Assume that account A,B,C have $100, $200, $300, respectively. 3 The result is incorrect, increasing the balancing of account B by $4 instead of $7. 3 U’update is lost because T overwrites it without seeing it Incorrect

5. Concurrency Control 서강대학교 정보통신 대학원 Need for Synchronization (Inconsistent Retrieval) $300B.Write(balance + 100) $200balance := B.Read() $300+.balance := balance + C.Read() $300balance := balance + B.Read() $100balance := A.Read( ) $100A.Write(balance-100) $200balance := A.Read( ) Bank$Deposit(B,100) Bank$BranchTotal( )Bank$Withdraw(A,100) Transaction U :Transaction T : 3 Assume that account A and B have all $200. 3 The result includes the sum of A and B as $300, not $400. 3 U’retrievals are inconsistent because T has performed only the withdrawal part of a transfer at the time the sum is calculated. Incorrect

6. Concurrency Control 서강대학교 정보통신 대학원 Solution to Inconsistent Retrieval Problem $400+.balance := balance + C.Read() $400balance := balance + B.Read() $100balance := A.Read( ) $300B.Write(balance + 100) $200balance := B.Read() $100A.Write(balance-100) $200balance := A.Read( ) Bank$Deposit(B,100) Bank$BranchTotal( )Bank$Withdraw(A,100) Transaction U :Transaction T : 3 We can avoid the inconsistent retrieval problem by performing all operations of transaction U only after all operations of transaction T have terminated, as above. But, can decrease the performance Correct

7. Concurrency Control 서강대학교 정보통신 대학원 Serial Equivalence (Serializability) 3 The use of serial equivalence as a criterion for correct concurrent execution prevents the occurrence of lost updates and inconsistent retrievals. 3 Concurrency control protocols should use this property to serialize transactions. $207B.Write(balance+3) $204balance := B.Read( ) $204B.Write(balance+4) $200balance := B.Read( ) $297C.Write(balance - 3) $300balance := C.Read( ) $96A.Write(balance-4) $100balance := A.Read( ) Bank$Deposit(B,3)Bank$Deposit(B,4) Bank$Withdraw(C,3)Bank$Withdraw(A,4) Transaction U :Transaction T : Correct

8. Concurrency Control 서강대학교 정보통신 대학원 Problems from Abort (Dirty Read) Abort transaction Commit transaction $108A.Write(balance + 5) $103balance := A.Read( ) $103A.Write(balance+3) $100balance := A.Read( ) Bank$Deposit(A,5)Bank.$Deposit(A,3) Transaction U :Transaction T : n The transaction U will have seen a value that never existed, since A will be restored to its original value. n As the transaction U has committed, it cannot be undone.

9. Concurrency Control 서강대학교 정보통신 대학원 Problem from Abort (Premature Write) n Related to the interaction between Write operations on the same data item belonging to different transactions n Before the transactions, the balance of account A was $100. n Before image concept: before image of T’s write - $100, before image of U’s write - $3. n T commits / U aborts (okay), U commits / T aborts (wrong balance). n To ensure correct result, Write operations must be delayed until earlier transactions that updated the same data items have either committed or aborted. $5A.Write(5) $3A.Write(3) Bank$SetBalance(A,5)Bank$SetBalance(A,3) Transaction U :Transaction T :

10. Concurrency Control 서강대학교 정보통신 대학원 Problem from Abort (Cascading Abort) n A single transaction failure leads to a series of transaction rollbacks. n Consider the following schedule where none of the transactions has yet committed. (so the schedule is recoverable) Read(A) Write(A) T2 Write(A) Read(B) Read(A) T3T1 n If T1 fails, T2 and T3 must also be rolled back. n Can lead to the undoing of a significant amount of work.

11. Concurrency Control 서강대학교 정보통신 대학원 Page 11 Strict Executions n Generally, it is required that transactions should delay both their Read and Write operations so as to avoid both “dirty read” and “premature write”. n The executions of transactions are called strict if the service delays both Read and Write operations on a data item until all transactions that previously wrote that data item have either committed or aborted. n The strict execution of transactions enforces the desired property of isolation.

12. Concurrency Control 서강대학교 정보통신 대학원 Page 12 Tentative Versions n A transaction must be designed so that any updates of the data items can be removed if and when a transaction aborts. n All of the update operations performed during a transaction are done in tentative versions of data items in volatile memory. n The tentative versions are transferred to the data items only when a transaction commits, by which time they will also have been recorded in permanent storage. n When a transaction aborts, its tentative versions are deleted.

13. Concurrency Control 서강대학교 정보통신 대학원 Page 13 Concurrency Control Transactions must be scheduled so that their effect on shared data is serially equivalent. 3 Serial equivalence requires that all of a transaction's accesses to a particular data item be serialized with respect to accesses by other transactions. Concurrency Control Protocols 3 Designed to cope with conflicts between operations in different transactions on the same data item. 3 A pair of operations conflicts : their combined effect depends on the order in which they are executed.

14. Concurrency Control 서강대학교 정보통신 대학원 Page 14 Three Concurrency Control Techniques (1) Locking 3 The server sets a lock on each data item just before it is accessed and removes these locks when the transaction has completed. 3 While a data item is locked, only the transaction that it is locked for can access that item. 3 Other transactions must either wait until the item is unlocked or in some cases, share the lock. 3 The use of locks can lead to deadlock.

15. Concurrency Control 서강대학교 정보통신 대학원 Page 15 Three Concurrency Control Techniques (2) Optimistic Concurrency Control 3 A transaction proceeds until it asks to commit. 3 Before it is allowed to commit, the server performs a check to discover whether it has performed operations on any data items that conflict with the operations of other concurrent transactions. Timestamp Ordering 3 A server records the most recent time of reading and writing each data item and for each operation. 3 The timestamp of the transaction is compared with that of the data item to determine whether it can be done immediately, delayed or rejected.

16. Concurrency Control 서강대학교 정보통신 대학원 Page 16 Locks (1) Two types of locks 3 Read locks Before a transaction’s Read operation is performed, the server attempt to set a read lock on the data item. 3 Write locks Before a transaction’s Write operation is performed, the server attempt to set a write lock on the data item. A request for a write lock on a data item is delayed by the presence of read lock belonging to another transaction. A request for either a read lock or a write lock on a data item is delayed by the presence of a write lock belonging to another transaction.

17. Concurrency Control 서강대학교 정보통신 대학원 Page 17 Locks (2) Two modes of locks 3 Exclusive Mode : no other transaction can concurrently lock the data item. 3 Shared Mode : other transactions can lock the data item. Lock compatibility For one data item Lock requested ReadWrite Lock already setNoneOK ReadOKWait WriteWait

18. Concurrency Control 서강대학교 정보통신 대학원 Page 18 Locks (3) Inconsistent Retrievals (Refer to slide #5) 3 Caused by conflicts between Read operations in one transaction and Write operations in another. 3 Prevented by performing the retrieval transaction before or after the update transaction. 3 If the retrieval transaction comes first, its read locks delay the update transaction. 3 If it comes second, its request for read locks causes it to be delayed until the update transaction has completed.

19. Concurrency Control 서강대학교 정보통신 대학원 Page 19 Locks (4) Lost Updates (Refer to slide #4) 3 Occur when two transactions read a value off data item and then use it to calculate a new value. 3 Prevented by making later transactions delay their reads until the earlier ones have completed. 3 This is achieved by each transaction setting a read lock when it reads a data item and then promoting it to a write lock when it writes the same data item. Lock promotion : the conversion of a lock to a stronger lock.

20. Concurrency Control 서강대학교 정보통신 대학원 Page 20 Locking Mechanisms (1) n Lock all the objects required by a transaction at its start and to release them on commit or abort. n Two Phase Locking (2PL) 3 Locks can be acquired as they are needed. 3 No lock can be released until all locks have been acquired. 3 Two Phase  First phase (growing phase) : A transaction may obtain locks, but may not release any lock.  Second phase (shrinking phase) : A transaction may release locks, but may not obtain any new locks. 3 A transaction can release locks as it finishes with the associated objects. => may not safe. 3 A safe procedure is to release all locks on commit. => strict 2PL

21. Concurrency Control 서강대학교 정보통신 대학원 Page 21 Locking Mechanisms (2) n Strict Two Phase Locking (Strict 2PL) 3 Strict executions are needed to prevent dirty reads and premature writes. 3 Transaction that needs to read or write a data item must be delayed until other transactions that wrote the same data item have committed or aborted. 3 To enforce this rule, any locks applied during the progress of a transaction are held until the transaction commits or aborts. 3 When a transaction commits, the locks must be held until all the data items it updated have been written to permanent storage. 3 Guarantees that all conflicting pairs of operations of two transactions are scheduled in the same order. (serializable schedule of transactions.)

22. Concurrency Control 서강대학교 정보통신 대학원 Page 22 Use of Locks in Strict 2PL 1. When an operation accesses a data item within a transaction: a) If the data item is not already locked, the server locks it and the operation proceeds. b) If the data item has a conflicting lock set by another transaction, the transaction must wait until it is unlocked. c) If the data item has a non-conflicting lock set by another transaction, the lock is shared and the operation proceeds. d) If the data item has already been locked In the same transaction, the lock will be promoted if necessary and the operation proceeds. (Where promotion is prevented by a conflicting lock, rule (b) is used.) 2. When a transaction is committed or aborted, the server unlocks all data items it locked for the transaction.

23. Concurrency Control 서강대학교 정보통신 대학원 Page 23 Lock Implementation Lock Manager 3 Responsible for maintaining a table of locks for the data items of a server. Entry in the table of locks 3 The transaction identifiers of the transactions that hold the lock. (shared locks can have several holders) 3 An identifier for a data item. 3 A lock type. 3 A condition variable. (Block the requester rather than retrying. Use wait and signal)

24. Concurrency Control 서강대학교 정보통신 대학원 Page 24 Lock Manager Functions Lock(Trans, DataItem, LockType) if there is a conflicting lock, that is, if there is an entry in the table belonging to another transaction that conflicts with DataItem, Wait on the condition variable associated with the entry. if (immediately or after a Wait) there are no conflicting locks: if there is no entry for DataItem, add an entry to the table of locks else if there is an entry for DataItem belonging to a different transaction, add Trans to the entry (share the lock) else if there is an entry for DataItem belonging to Trans and LockType is more exclusive than the type in the entry, change entry to LockType (promote lock). Unlock(Trans) if there are any entries in the table belonging to transaction Trans, for each entry : if there is only one holder (Trans) in the entry, remove the entry else (a shared lock) remove Trans from the entry and Signal the associated condition variable.

25. Concurrency Control 서강대학교 정보통신 대학원 Page 25 Deadlocks Deadlock 3 A state in which each member of a group of transactions is waiting for some other member to release a lock. Wait-for graph 3 Used to represent the waiting relationships between current transactions at a server. Nodes : transactions Edges : wait-for relationships between transactions There is an edge from node T to node U when transaction T is waiting for transaction U to release a lock.

26. Concurrency Control 서강대학교 정보통신 대학원 Page 26 Deadlock with Read and Write Locks Transaction T :Transaction U : OperationsLocksOperationsLocks balance := A.Read( )read locks A balance := C.Read( )read locks C C.Write(balance-3)write locks C A.Write(balance-4)write locks A... balance := B.Read( )locks B balance := B.Read( )shares read lock on B B.Write(balance+4)wait for U...B.Write(balance+3)wait for T...

27. Concurrency Control 서강대학교 정보통신 대학원 Page 27 The Wait-for Graph for Slide #26 T T U U T T U U B B A A C C Held by Waits for If a wait-for graph contains a cycle, then all of these transactions are blocked waiting for locks. If one of the transactions in a cycle is aborted, then its locks are released and that cycle is broken.

28. Concurrency Control 서강대학교 정보통신 대학원 Page 28 Deadlock Prevention n Lock all of the data items used by transaction when it starts. 3 An apparently simple, but not very good way. 3 It unnecessarily restricts access to shared resources. 3 It is sometimes impossible to predict at the start of a transaction which data items will be used. n Requesting locks on data items in a predefined order. 3 This can result in premature locking and reduction in concurrency.

29. Concurrency Control 서강대학교 정보통신 대학원 Page 29 Deadlock Detection n By finding cycles in the wait-for graph. n Deadlock detection software, part of the lock manager, must hold a representation of the wait-for graph so that it can check it for cycles. 3 Edges are added to the graph and removed from the graph by the lock manager's Lock and Unlock operations. n The presence of cycles may be checked each time an edge is added, or less frequently to avoid server overhead. n The choice of the transaction to abort is not simple. 3 Some factors : the age of the transaction, the number of cycles it is involved in.

30. Concurrency Control 서강대학교 정보통신 대학원 Page 30 Deadlock Resolution n Lock timeouts 3 A method for resolution of deadlocks that is commonly used. 3 Each lock is given a limited period in which it is invulnerable. After this time, a lock becomes vulnerable. 3 If any transaction access the data item protected by a vulnerable lock, the lock is broken and the waiting transaction resumes. The transaction whose lock has been broken is normally aborted. n Problems with the use of timeouts 3 Transactions are sometimes aborted due to their locks becoming vulnerable when other transactions are waiting for them, but there is actually no deadlock. (in an overloaded system) 3 It is hard to decide on an appropriate length for a timeout.

31. Concurrency Control 서강대학교 정보통신 대학원 Page 31 Deadlock Resolution using Timeout Transaction T :Transaction U : OperationsLocksOperationsLocks balance := A.Read( )read locks A balance := C.Read( )read locks C C.Write(balance-3)write locks C A.Write(balance-4)write locks A... balance := B.Read( )read locks B balance := B.Read( )shares read lock on B B.Write(balance+4)waits on U’s read lock on B...B.Write(balance+3)waits on T’s read lock on B timeout elapses... T’s lock on B becomes vulnerable unlocks B, abort T B.Write(balance+3)write locks B / unlocks B, C

32. Concurrency Control 서강대학교 정보통신 대학원 Page 32 Optimistic Concurrency Control (OCC) The drawbacks of locking 3 Lock maintenance represents an overhead that is not present in systems that do not support concurrent access to shared data. 3 The use of locks can result in deadlock. 3 To avoid cascading aborts, locks cannot be released until the end of the transaction. The alternative approach : Optimistic Concurrency Control : It is based on the observation that, in most applications, the likelihood of two clients' transactions accessing the same data is low.

33. Concurrency Control 서강대학교 정보통신 대학원 Page 33 Three Phases in OCC (1) Read phase 3 During the read phase, each transaction has a tentative version of each of the data items that it updates. 3 Read operations are performed immediately. If a tentative version for that transaction already exists, a read operation accesses it, otherwise it accesses the most recently committed value of the data item. 3 Write operations record the new values of the data items as tentative values. (internal to the transaction)

34. Concurrency Control 서강대학교 정보통신 대학원 Page 34 Three Phases in OCC (2) Validation phase 3 When the CloseTransaction request is received, the transaction is validated to establish whether or not its operations on data items conflict with operations of other transactions on the same data items. Write phase 3 If a transaction is validated, all of the changes recorded in its tentative versions are made permanent (commit). Otherwise, rollback.

35. Concurrency Control 서강대학교 정보통신 대학원 Page 35 Validation of Transactions Validation 3 Uses the Read/write conflict rules to ensure that the scheduling of a particular transaction is serially equivalent with respect to all other overlapping transactions. 3 To assist in performing validation, each transaction is assigned a transaction number in ascending sequence when it enters the validation phase. Transaction number defines its position in time. 3 As the validation and write phases of a transaction are generally short in duration compared with the read phase, a simplification may be achieved by making the rule that only one transaction may be in the validation and write phase at one time. (Rule 3 is satisfied.) 3 To prevent overlapping, the entire validation and write phases can be implemented as a critical section.

36. Concurrency Control 서강대학교 정보통신 대학원 Page 36 Read / Write Conflict Rules TiTi TjTj Rule ReadWrite1. T i must not read data items written by T j. WriteRead2. T j must not read data items written by T i. Write 3. T i must not write data items written by T j and T j must not write data items written by T i.

37. Concurrency Control 서강대학교 정보통신 대학원 Page 37 Overlapping Transactions Read Validation Write T1T1 T2T2 T3T3 TjTj active1 active2 Transaction being validated Later active transactions Earlier committed transactions

38. Concurrency Control 서강대학교 정보통신 대학원 Page 38 Backward Validation n Checks the transaction undergoing validation with other preceding overlapping transactions n The validation of transaction T j checks whether its read set (the data items affected by the Read operations of T j ) overlaps with any of the write sets of earlier overlapping transactions T i. 3 If there is any overlap, the validation fails. n The read set of the transaction being validated is compared with the write sets of other transactions that have already committed. n Transactions that have no Read operations need not be checked. n The write sets of old committed versions of data items corresponding to recently committed transactions are retained until there are no unvalidated overlapping transactions with which they might conflict.

39. Concurrency Control 서강대학교 정보통신 대학원 Page 39 Algorithm for Backward Validation Algorithm for backward validation of T j 3 startTn : the biggest transaction number assigned (to some other committed transaction) at the time when transaction T j started its read phase. 3 finishTn : the biggest transaction number assigned at the time when T j entered the validation phase. Valid := TRUE ; FOR T i := startTn +1 TO finishTn DO IF read set of T j intersects write set of T i THEN Valid := FALSE ; END Valid := TRUE ; FOR T i := startTn +1 TO finishTn DO IF read set of T j intersects write set of T i THEN Valid := FALSE ; END

40. Concurrency Control 서강대학교 정보통신 대학원 Page 40 Forward Validation Forward validation 3 The write set of T j compared with the read sets of all overlapping active transactions - those that are in still in their read phase. (Rule 1) 3 Read only transactions always pass the validation check. (Rule 2 is satisfied) Some alternative way of resolving the conflict 3 Defer the validation until a later time when the conflicting transactions have finished. 3 Abort all the conflicting active transactions and commit the transaction being Validated. 3 Abort the transaction being validated.

41. Concurrency Control 서강대학교 정보통신 대학원 Page 41 Algorithm for Forward Validation Algorithm for forward validation of T j 3 active1, active2 : the active transactions have (consecutive) transaction identifiers. Valid := TRUE ; FOR Tid:= active1 TO activeN DO IF write set of T j intersects read set of Tid THEN Valid := FALSE ; END Valid := TRUE ; FOR Tid:= active1 TO activeN DO IF write set of T j intersects read set of Tid THEN Valid := FALSE ; END

42. Concurrency Control 서강대학교 정보통신 대학원 Page 42 Comparison of Two Approaches Forward validation 3 Allows flexibility in the resolution of conflicts. 3 Checks a small write set against the of read sets of active transactions. 3 Has to allow for new transactions starting during the validation process. Backward validation 3 Allows only one choice - to abort the transaction being validated. 3 Compares a possibly large read set against the old write sets. 3 Has the overhead of storing old write sets until they are no longer needed.

43. Concurrency Control 서강대학교 정보통신 대학원 Page 43 Starvation : The deprivation of a transaction from ever being able to commit. 3 The server detects a transaction that has been aborted several times. 3 When the server detects such a transaction it should be given exclusive access by the use of a critical section protected by a semaphore.

44. Concurrency Control 서강대학교 정보통신 대학원 Page 44 Timestamp Ordering (1) Each transaction is assigned a unique timestamp value when it starts. 3 Timestamp : its position in the time sequence of transactions. 3 Using timestamps, requests from transactions can be totally ordered. A server may use its clock to assign timestamps or it may use a 'pseudo-time‘ based on a counter. Every data item has a write timestamp and a set of tentative versions, and a set of read timestamps. 3 Whenever a transaction's Write operation on a data item is accepted the server creates a new tentative version of the data item with write timestamp set to the transaction timestamp. 3 A transaction's Read operation is directed to the version with the maximum write timestamp less than the transaction timestamp.

45. Concurrency Control 서강대학교 정보통신 대학원 Page 45 Timestamp Ordering (2) Basic timestamp ordering rule based on operation conflicts 3 Write operations may be performed without making the client wait. 3 The client must wait when Read operations need to wait for earlier transactions to finish. (cannot lead to deadlock since transactions only wait for earlier ones.) A transaction's request to write a data item is valid only if that data item was last read and written by earlier transactions. A transaction's request to read a data item is valid only if that data item was last written by an earlier transaction. A transaction's request to write a data item is valid only if that data item was last read and written by earlier transactions. A transaction's request to read a data item is valid only if that data item was last written by an earlier transaction.

46. Concurrency Control 서강대학교 정보통신 대학원 Page 46 Timestamp Ordering (3) RuleTjTj 1.Write T j must not write a data item that has been read by any T i where T i > T j, this requires that T j ≥ the maximum read timestamp of the data item. 2.Write T j must not write a data item that has been written by any T i where T i > T j, this requires that T j > the maximum write timestamp of the committed data item. 3.Read T j must not read a data item that has been written by any T i where T i > T j, this implies that T j cannot read if T j < write timestamp of the committed version of the data item. Transaction conflict for timestamp ordering

47. Concurrency Control 서강대학교 정보통신 대학원 Page 47 Timestamp Ordering Write Rule 3 If a tentative version with write timestamp T j already exists, the Write operation is addressed to it, otherwise a new tentative version is created and given write timestamp T j. IF T j ≥ maximum read timestamp on D AND T j > write timestamp on committed version of D THEN perform Write operation on tentative version of D with timestamp T j ELSE (* write is too late *) Abort transaction T j END IF T j ≥ maximum read timestamp on D AND T j > write timestamp on committed version of D THEN perform Write operation on tentative version of D with timestamp T j ELSE (* write is too late *) Abort transaction T j END

48. Concurrency Control 서강대학교 정보통신 대학원 Page 48 Write Operations and Timestamps T2T2 T2T2 Before T2T2 T2T2 After T3T3 T3T3 TIME a) T3 Write T2T2 T2T2 Before T2T2 T2T2 After T3T3 T3T3 TIME c) T3 Write T4T4 T4T4 T4T4 T4T4 T4T4 T4T4 Before T4T4 T4T4 After TIME d) T3 Write T1T1 T1T1 Before T1T1 T1T1 After T2T2 T2T2 TIME b) T3 Write T2T2 T2T2 T3T3 T3T3 : Committed ( ) / Tentative ( )data item produced by Ti, T1<T2<T3<T4 Ti Transaction aborts

49. Concurrency Control 서강대학교 정보통신 대학원 Page 49 Timestamp Ordering Read Rule IF T j > write timestamp on committed version of D THEN let D selected be the version of D with the maximum write timestamp ≤ T j IF D selected if committed THEN perform Read operation on the version D selected ELSE wait until the transaction that made version D selected commits or aborts then re-apply the read rule ELSE Abort transaction T j END IF T j > write timestamp on committed version of D THEN let D selected be the version of D with the maximum write timestamp ≤ T j IF D selected if committed THEN perform Read operation on the version D selected ELSE wait until the transaction that made version D selected commits or aborts then re-apply the read rule ELSE Abort transaction T j END

50. Concurrency Control 서강대학교 정보통신 대학원 Page 50 Read Operations and Timestamps T2T2 T2T2 TIME a) T3 Read T1T1 T1T1 TIME c) T3 Read T2T2 T2T2 T4T4 T4T4 TIME d) T3 Read T2T2 T2T2 TIME b) T3 Read T4T4 T4T4 : Committed ( ) / Tentative ( )data item produced by Ti, T1<T2<T3<T4 Ti Transaction aborts Read proceeds Read proceeds Read waits Selected

51. Concurrency Control 서강대학교 정보통신 대학원 Page 51 Recoverability 3 In order to make a transaction recoverable after a server crash, the tentative versions of data items and the fact that the transaction has committed must be written to permanent storage before acknowledging the client's request to commit the transaction. A modification to the Timestamp Ordering Write rule 3 If a write is too late it can be ignored instead of aborting the transaction, because if it had arrived in time its effects would have been overwritten anyway. However, if another transaction has read the data item, the transaction with the late write due to the read timestamp on the item.

52. Concurrency Control 서강대학교 정보통신 대학원 Page 52 Timestamps in Transactions T and U Timestamps and versions of data items Transaction TTransaction U ABC RTS WTS { } S OpenTransaction bal : = A.Read( ) { T } OpenTransaction bal : = C.Read( ) { U } A.Write(bal-4) S, T bal : = B.Read( ) { T } C.Write(bal-3) S, U bal : = B.Read( ) { U } B.Write(bal+4) Aborts B.Write(bal+3) S, U

53. Concurrency Control 서강대학교 정보통신 대학원 Page 53 Comparison of Three Methods (1) Pessimistic approaches 3 Serialization order Timestamp ordering method : decides the serialization order statically - when a transaction starts. Two-phase locking : decides the serialization order dynamically - according to the order in which data items are accessed. 3 Operational benefit Timestamp ordering method : better than strict two-phase locking for read only transactions. Two-phase locking : better when the operations in transactions are predominantly updates. 3 When a conflicting access Timestamp ordering method : aborts the transaction immediately Two-phase locking : makes the transaction wait

54. Concurrency Control 서강대학교 정보통신 대학원 Page 54 Comparison of Three Methods (2) Optimistic concurrency control 3 All transactions are allowed to proceed, but some are aborted when they attempt to commit, or in forward validation transactions are aborted earlier. Relatively efficient operation when there are few conflicts. A substantial amount of work may have to be repeated when a transaction is aborted. Two new requirement for multi-user applications 3 Users require immediate notification of changes made by other users. 3 Users need to be able to access data items before other users have completed their transactions

55. Concurrency Control 서강대학교 정보통신 대학원 Page 55 Comparison of Three Methods (3) Advanced database applications feature 3 Transactions last for a long time. 3 Users work on independent versions of data items that are checked out from a common database and checked in when the work is finished. 3 The merging of versions requires co-operation between user.