DB2 Lecture 10 Concurrency Control

Transcription

1 DB2 Lecture 10 Control Jacob Aae Mikkelsen November 28, / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

2 ACID Properties Properly implemented transactions are commonly said to meet the ACID test, where: Atomicity The all-or-nothing execution of transactions. Isolation Each transaction must appear to be executed as if no other transaction is executing at the same time. Durability The effect on the database of a transaction must never be lost, once the transaction has completed. Consistency All databases have consistency constraints, or expectations about relationships among data elements (e.g., account balances may not be negative after a transaction finishes). Transactions are expected to preserve the consistency of the database. 2 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

3 Example Constraint: A = B In isolation, each transaction preserves consistancy. 3 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

4 Important terms Schedule the sequence of actions performed by transactions 4 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

5 Important terms Schedule the sequence of actions performed by transactions Serial Schedule A schedule is serial if its actions consist of all the actions of one transaction, then all the actions of another transaction, so on. No mixing of the actions is allowed. 4 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

6 Important terms Schedule the sequence of actions performed by transactions Serial Schedule A schedule is serial if its actions consist of all the actions of one transaction, then all the actions of another transaction, so on. No mixing of the actions is allowed. Serializable schedules produce the same result as if the transactions executed one-at-a-time a schedule S is serializable if there is a serial schedule S such that for every initial database state, the effects of S S are the same. 4 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

7 Serial 5 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

8 Serial 6 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

9 Serializable Equivalent to the serial schedule (T 1, T 2 ) from Fig / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

10 A nonserializable schedule Leaves the database in an inconsistant state. 8 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

11 Notation Shorth notation 1 An action is an expression of the form r i (X ) or W i (X ), meaning that transaction T, reads or writes, respectively, the database element X. 2 A transaction T i is a sequence of actions with subscript i. 3 A schedule S of a set of transactions τ is a sequence of actions, in which for each transaction T i in τ, the actions of T i appear in S in the same order that they appear in the definition of T i itself. We say that S is an interleaving of the actions of the transactions of which it is composed. 9 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

12 Example Transactions of running example 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); 10 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

13 Example Transactions of running example 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); The serializable schedule from Fig r 1 (A); w 1 (A); r 2 (A); w 2 (A); r 1 (B); w 1 (B); r 2 (B); w 2 (B); 10 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

14 Stronger condition than serializability just defined Used all in commercial systems A 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. 11 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

15 Conflicts Non-conflicts 1 r i (X ); r j (Y ) is never a conflict, even if X = Y. The reason is that neither of these steps change the value of any database element. 2 r i (X ); W j (Y ) is not a conflict provided X Y. The reason is that should T j write Y before T i reads X, the value of X is not changed. Also, the read of X by T i has no effect on T j, so it does not affect the value T j writes for Y. 3 W i (X ); r j (Y ) is not a conflict if X Y, for the same reason as (2). 4 Similarly, W i (X ); W j (Y ) is not a conflict as long as X Y. 12 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

16 Conflicts Conflicts Two actions of the same transaction, e.g., r i (X ); W i (Y ), always conflict. The reason is that the order of actions of a single transaction are fixed may not be reordered. Two writes of the same database element by different transactions conflict. That is, W i (X ); W j (X ) is a conflict. The reason is that as written, the value of X remains afterward as whatever T j computed it to be. If we swap the order, as W j (X ); W i (X ), then we leave X with the value computed by T i 13 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

17 Conflicts Conflicts A read a write of the same database element by different transactions also conflict. That is, r i (X ); w j (X ) is a conflict, so is w i (X ); r j (X ). If we move w j (X ) ahead of ri(x ), then the value of X read by T i will be that written by T j, which we assume is not necessarily the same as the previous value of X. Thus, swapping the order of r i (X ) w j (X ) affects the value T i reads for X could therefore affect what T i does. 14 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

18 Conflicts Conflicts A read a write of the same database element by different transactions also conflict. That is, r i (X ); w j (X ) is a conflict, so is w i (X ); r j (X ). If we move w j (X ) ahead of ri(x ), then the value of X read by T i will be that written by T j, which we assume is not necessarily the same as the previous value of X. Thus, swapping the order of r i (X ) w j (X ) affects the value T i reads for X could therefore affect what T i does. The conclusion we draw is that any two actions of different transactions may be swapped unless: 1 They involve the same database element, 2 At least one is a write. 14 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

19 conflict-serializable conflict-equivalent We say that two schedules are conflict-equivalent if they can be turned one into the other by a sequence of nonconflicting swaps of adjacent actions. 15 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

20 conflict-serializable conflict-equivalent We say that two schedules are conflict-equivalent if they can be turned one into the other by a sequence of nonconflicting swaps of adjacent actions. conflict-serializable We shall call a schedule conflict-serializable if it is conflict-equivalent to a serial schedule. 15 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

21 conflict-serializable serializability is a sufficient condition for serializability A conflict-serializable schedule is a serializable schedule. serializability is not required for a schedule to be serializable, but it is the condition that the schedulers in commercial systems generally use when they need to guarantee serializability. 16 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

22 Example Is this schedule conflict serializable? 17 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

23 Example Is this schedule conflict serializable? 17 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

24 When a pair of conflicting actions appears anywhere in S, the transactions performing those actions must appear in the same order in any conflict-equivalent serial schedule as the actions appear in S. Conflicting pairs of actions put constraints on the order of transactions in the hypothetical, conflict-equivalent serial schedule. If these constraints are not contradictory, we can find a conflict-equivalent serial schedule. If they are contradictory, we know that no such serial schedule exists. 18 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

25 Given a schedule S, involving transactions T 1 T 2, perhaps among other transactions, we say that T 1 takes precedence over T 2, written T 1 < s T 2, if there are actions A 1 of T 1 A 2 of T 2, such that: 1 A 1 is ahead of A 2 in S, 2 Both A 1 A 2 involve the same database element, 3 At least one of A 1 A 2 is a write action. 19 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

26 Given a schedule S, involving transactions T 1 T 2, perhaps among other transactions, we say that T 1 takes precedence over T 2, written T 1 < s T 2, if there are actions A 1 of T 1 A 2 of T 2, such that: 1 A 1 is ahead of A 2 in S, 2 Both A 1 A 2 involve the same database element, 3 At least one of A 1 A 2 is a write action. As a result, a conflict-equivalent serial schedule must have T 1 before T / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

27 Graph The nodes of the precedence graph are the transactions of a schedule S. When the transactions are T i for various i, we shall label the node for T j by only the integer i. There is an arc from node i to node j if T j < s T j. 20 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

28 Graph The nodes of the precedence graph are the transactions of a schedule S. When the transactions are T i for various i, we shall label the node for T j by only the integer i. There is an arc from node i to node j if T j < s T j. To tell whether a schedule S is conflict-serializable, construct the precedence graph for S ask if there are any cycles. If so, then S is not conflict-serializable. If the graph is acyclic, then S is conflict-serializable, moreover, any topological order of the nodes is a conflict-equivalent serial order. 20 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

29 Example What conflicts are there? 21 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

30 Example What conflicts are there? T 2 < s T 3 T 1 < s T 2 How will the graph look? 21 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

31 Example What conflicts are there? T 2 < s T 3 T 1 < s T 2 How will the graph look? 21 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

32 Example What conflicts are there? 22 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

33 Example What conflicts are there? T 2 < s T 3 T 1 < s T 2 T 2 < s T 1 How will the graph look? 22 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

34 Example What conflicts are there? T 2 < s T 3 T 1 < s T 2 T 2 < s T 1 How will the graph look? 22 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

35 Locks 23 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

36 Locks (basic) When a scheduler uses locks, transactions must request release locks, in addition to reading writing database elements. Consistency of Transactions 1 A transaction can only read or write an element if it previously was granted a lock on that element hasn t yet released the lock. 2 If a transaction locks an element, it must later unlock that element. Legality of 1 Locks must have their intended meaning: no two transactions may have locked the same element without one having first released the lock. 24 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

37 Notation l i (X ) Transaction T i requests a lock on database element X. u i (X ) Transaction T i releases ( unlocks ) its lock on database element X. 25 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

38 Example 26 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

39 Example 27 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

40 Example 28 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

41 Two-Phase Locking 2PL In every transaction, all lock actions precede all unlock actions. 29 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

42 Two-Phase Locking 2PL In every transaction, all lock actions precede all unlock actions. Guarantee that a legal schedule of consistent transactions is conflict- serializable 29 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

43 Two-Phase Locking 2PL In every transaction, all lock actions precede all unlock actions. Guarantee that a legal schedule of consistent transactions is conflict- serializable Phase 1: Obtaining locks Phase 2: Releasing locks 29 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

44 2PL 30 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

45 Shared Exclusive Locks 2 types of locks shared lock or read lock exclusive lock or write lock 31 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

46 Notation sl i (X ) Transaction T i requests a shared lock on database element X. xl i (X ) Transaction T i requests an exlusive lock on database element X. u i (X ) Transaction T i releases ( unlocks ) its lock on database element X. 32 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

47 Shared Exclusive Locks Consistency of Transactions 1 A transaction may not write without holding an exclusive lock, you may not read without holding some lock. Two-phase locking of transactions 1 Locking must precede unlocking. Legality of 1 An element may either be locked exclusively by one transaction or by several in shared mode, but not both. 33 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

48 Example 34 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

49 Example 35 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

50 Compatibility Matrices 36 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

51 Compatibility Matrices Upgrading Locks Request an exclusive lock on X in addition to its already held shared lock on X 36 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

52 Example 37 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

53 Example 38 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

54 39 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

55 Update Locks An update lock ul i (X ) gives transaction T i only the privilege to read X, not to write X Only the update lock can be upgraded; a read lock cannot be upgraded to a write lock later Can grant an update lock on X when there are already shared locks on X, but once there is an update lock on X we prevent additional locks of any kind Prevents deadlocks 40 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

56 Methods Timestamping Assign a timestamp to each transaction. Record the timestamps of the transactions that last read write each database element, compare these values with the transactions timestamps, to assure that the serial schedule according to the transactions timestamps is equivalent to the actual schedule of the transactions. 41 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

57 Methods Timestamping Assign a timestamp to each transaction. Record the timestamps of the transactions that last read write each database element, compare these values with the transactions timestamps, to assure that the serial schedule according to the transactions timestamps is equivalent to the actual schedule of the transactions. Validation Examine timestamps of the transaction the database elements when a transaction is about to commit; this process is called validation of the transaction. The serial schedule that orders transactions according to their validation time must be equivalent to the actual schedule. 41 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

58 Differences Locking based Assume that things will go wrong unless transactions are prevented in advance from engaging in nonserializable behavior. 42 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

59 Differences Locking based Assume that things will go wrong unless transactions are prevented in advance from engaging in nonserializable behavior. Timestamp based Optimistic, in the sense that they assume that no unserializable behavior will occur only fix things up when a violation is apparent. 42 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

60 The scheduler assign to each transaction T a unique number, its timestamp TS(T ) must be issued in ascending order, at the time that a transaction first notifies the scheduler that it is beginning Use the system clock as the timestamp or maintain a counter 43 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

61 associate with each database element X two timestamps an additional bit 1 RT (X ), the read time of X, which is the highest timestamp of a transaction that has read X. 2 WT (X ), the write time of X, which is the highest timestamp of a transaction that has written X. 3 C(X ), the commit bit for X, which is true if only if the most recent transaction to write X has already committed. The purpose of this bit is to avoid a situation where one transaction T reads data written by another transaction U, U then aborts. (Dirty read) 44 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

62 Physically Unrealizable Behaviors Timestamp order is also assumed order the transactions execute. 45 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

63 Physically Unrealizable Behaviors Timestamp order is also assumed order the transactions execute. Check that whenever a read or write occurs, what happens in real time could have happened if each transaction had executed instantaneously at the moment of its timestamp. If not, we say the behavior is physically unrealizable. 45 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

64 Potential problems Read too late Transaction T tries to read database element X, but the write time of X indicates that the current value of X was written after T theoretically executed; that is, TS(T ) < WT (X ). 46 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

65 Potential problems Read too late Transaction T tries to read database element X, but the write time of X indicates that the current value of X was written after T theoretically executed; that is, TS(T ) < WT (X ). 46 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

66 Potential problems Write too late Transaction T tries to write database element X. How ever, the read time of X indicates that some other transaction should have read the value written by T, but read some other value instead. That is, WT (X ) < TS(T ) < RT (X ). 47 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

67 Potential problems Write too late Transaction T tries to write database element X. How ever, the read time of X indicates that some other transaction should have read the value written by T, but read some other value instead. That is, WT (X ) < TS(T ) < RT (X ). 47 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

68 Potential problems Dirty read Transaction T reads X, X was last written by U. The timestamp of U is less than that of T, the read by T occurs after the write by U in real time, so the event seems to be physically realizable. However, it is possible that after T reads the value of X written by U, transaction U will abort. We can tell that U is not committed because the commit bit C(X ) will be false. 48 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

69 Potential problems Dirty read Transaction T reads X, X was last written by U. The timestamp of U is less than that of T, the read by T occurs after the write by U in real time, so the event seems to be physically realizable. However, it is possible that after T reads the value of X written by U, transaction U will abort. We can tell that U is not committed because the commit bit C(X ) will be false. 48 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

70 Rules for Timestamp-Based Scheduling In response to a read or write request from a transaction T has the choice of: 1 Granting the request, 2 Aborting T (if T would violate physical reality) restarting T with a new timestamp (abort followed by restart is often called rollback), or 3 Delaying T later deciding whether to abort T or to grant the request. (If the request is a read, the read might be dirty) 49 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

71 Rules for read request 50 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

72 Rules for write request 51 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

73 Rules for commit request 52 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

74 Rules for abort/rollback request 53 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

75 Rules for abort/rollback request 54 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

76 Multiversion maintains old versions of database elements in addition to the current version that is stored in the database itself. purpose is to allow reads r T (X ) that otherwise would cause transaction T to abort (because the current version of X was written in T s future) to proceed by reading the version of X that is appropriate for a transaction with T s timestamp. Especially useful if database elements are disk blocks or pages, since then all that must be done is for the buffer manager to keep in memory certain blocks that might be useful for some currently active transaction 55 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

77 Multiversion There is an old value of A written by T 1 overwritten by T 2 that would have been suitable for T 3 to read; this version of A had a write time of 150, which is less than T 3 s timestamp of 175. If this old value of A were available, T3 could be allowed to read it, even though it is not the current value of A. 56 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

78 Multiversion 57 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

79 Validation The short version Three fases Read In the first phase, the transaction reads from the database all the elements in its read set. The transaction also computes in its local address space all the results it is going to write. Validate In the second phase, the scheduler validates the transaction by comparing its read write sets with those of other transactions. If validation fails, then the transaction is rolled back; otherwise it proceeds to the third phase. Write In the third phase, the transaction writes to the database its values for the elements in its write set. 58 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

80 Versus Locking are better in situations where either most transactions are read-only, or it is rare that concurrent transactions will try to read write the same element. 59 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

81 Versus Locking are better in situations where either most transactions are read-only, or it is rare that concurrent transactions will try to read write the same element. Locking are better In high-conflict situations 59 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

82 Versus Locking are better in situations where either most transactions are read-only, or it is rare that concurrent transactions will try to read write the same element. Locking are better In high-conflict situations Rule-of-thumb Locking will frequently delay transactions as they wait for locks. If concurrent transactions frequently read write elements in common, then rollbacks will be frequent in a timestamp scheduler, introducing even more delay than a locking system. 59 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

83 Versus Locking Locking delays transactions but avoids rollbacks, even when interaction is high. validation do not delay transactions, but can cause them to rollback, which is a more serious form of delay also wastes resources. If interference is low, then neither timestamps nor validation will cause many rollbacks, may be preferable to locking because they generally have lower overhead than a locking scheduler. When a rollback is necessary, timestamps catch some problems earlier than validation, which always lets a transaction do all its internal work before considering whether the transaction must rollback. 60 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

84 In practice In practice, both are used Scheduler divides transactions into read-only read-write read-write: executed using two-phase locking, to keep all transactions from accessing the elements they lock. read-only: Read-only transactions are executed using multiversion timestamping. A read-only transaction is allowed to read whatever version of a database element is appropriate for its timestamp. A read-only transaction thus never has to abort, will only rarely be delayed. 61 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

85 The Dirty-data problem (No commit bit used) 62 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

86 Cascading rollbacks Dirty-reads Can cause cascading rollbacks, when a transaction aborts Uses the log to rollback effects of the transaction. timestamp-based scheduler with a commit bit pre vents a transaction that may have read dirty data from proceeding A validation-based scheduler avoids cascading rollback, because writing to the database (even in buffers) occurs only after it is determined that the transaction will commit. 63 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

87 Recoverable To allow recovery, the set of transactions that are regarded as committed after recovery must be consistent. That is, if a transaction T 1 is, after recovery, regarded as committed, T 1 used a value written by T 2, then T 2 must also remain committed, after recovery. 64 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

88 Recoverable To allow recovery, the set of transactions that are regarded as committed after recovery must be consistent. That is, if a transaction T 1 is, after recovery, regarded as committed, T 1 used a value written by T 2, then T 2 must also remain committed, after recovery. A schedule is recoverable if each transaction commits only after each transaction from which it has read has committed. 64 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

89 Recoverable To allow recovery, the set of transactions that are regarded as committed after recovery must be consistent. That is, if a transaction T 1 is, after recovery, regarded as committed, T 1 used a value written by T 2, then T 2 must also remain committed, after recovery. A schedule is recoverable if each transaction commits only after each transaction from which it has read has committed. Assumption The log s commit records reach disk in the order in which they are written. 64 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

90 Avoid Cascading Rollback ACR schedule A schedule avoids cascading rollback (or is an ACR schedule ) if transactions may read only values written by committed transactions. 65 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

91 Avoid Cascading Rollback ACR schedule A schedule avoids cascading rollback (or is an ACR schedule ) if transactions may read only values written by committed transactions. Every ACR schedule is recoverable. 65 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

92 Avoid Cascading Rollback ACR schedule A schedule avoids cascading rollback (or is an ACR schedule ) if transactions may read only values written by committed transactions. Every ACR schedule is recoverable. Strict Locking commonly used way to guarantee that there are no cascading rollbacks A transaction must not release any exclusive locks until the transaction has either committed or aborted, the commit or abort log record has been flushed to disk. 65 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

93 66 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

94 67 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

95 Typically one of the transactions must be aborted restarted 67 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

96 - solution Detection Timeout: Put a limit on how long a transaction may be active, if a transaction exceeds this time, roll it back. Waits-For Graph: Can be used to either detect deadlocks. If no cycles in the graph, the transactions will be able to complete. 68 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

97 - solution Detection Timeout: Put a limit on how long a transaction may be active, if a transaction exceeds this time, roll it back. Waits-For Graph: Can be used to either detect deadlocks. If no cycles in the graph, the transactions will be able to complete. Prevention Don t allow a lock that creates a cycle in the Waits-For Graph, abort restart transaction. 68 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

98 - solution Waits-For Graph Nodes are transactions, arcs from T to U if: 1 U holds a lock on A, 2 T is waiting for a lock on A, 3 T cannot get a lock on A in its desired mode unless U first releases its lock on A 69 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

99 - solution Detecting by Associate with each transaction a timestamp, for deadlock detection only When a transaction T has to wait for a lock that is held by another transaction U, one of the following schemes are used 70 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

100 - solution Detecting by Associate with each transaction a timestamp, for deadlock detection only When a transaction T has to wait for a lock that is held by another transaction U, one of the following schemes are used In the wait-die scheme, you can only wait for younger transactions. In the wound-wait scheme, you can only wait for older transactions. 70 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

101 - solution The Wait-Die Scheme 1 If T is older than U (timestamp of T is smaller than U s), then T is allowed to wait for the lock(s) held by U. 2 If U is older than T, then T dies ; it is rolled back. 71 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control

102 - solution The Wait-Die Scheme 1 If T is older than U (timestamp of T is smaller than U s), then T is allowed to wait for the lock(s) held by U. 2 If U is older than T, then T dies ; it is rolled back. The Wound-Wait Scheme 1 If T is older than U, it wounds U. Usually, the wound is fatal: U must roll back relinquish to T the lock(s) that T needs from U. There is an exception if, by the time the wound takes effect, U has already finished released its locks. In that case, U survives need not be rolled back. 2 If U is older than T, then T waits for the lock(s) held by U. 71 / 71 Jacob Aae Mikkelsen DB2 Lecture 10 Control