Presentation is loading. Please wait.

Presentation is loading. Please wait.

Assignment 3 -- Solution 1. Problem 1 H 1 : r 1 [y] r 1 [x] r 2 [x] w 1 [y] c 1 w 2 [y] c 2 H 1 is normally-strict two-phase locked: rl 1 [y] r 1 [y]

Similar presentations


Presentation on theme: "Assignment 3 -- Solution 1. Problem 1 H 1 : r 1 [y] r 1 [x] r 2 [x] w 1 [y] c 1 w 2 [y] c 2 H 1 is normally-strict two-phase locked: rl 1 [y] r 1 [y]"— Presentation transcript:

1 Assignment 3 -- Solution 1

2 Problem 1 H 1 : r 1 [y] r 1 [x] r 2 [x] w 1 [y] c 1 w 2 [y] c 2 H 1 is normally-strict two-phase locked: rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] wl 1 [y] w 1 [y] c 1 ru 1 [x] wu 1 [y] wl 2 [y] w 2 [y] c 2 ru 2 [x] wu 2 [y] Note that ru 1 [y] isn’t needed, since ru 1 [y] was converted into wu 1 [y], i.e., T 1 holds only one lock on y. 2

3 H 2 : r 1 [y] r 1 [x] r 2 [x] w 2 [x] w 1 [y] c 1 w 2 [y] c 2 H 2 is two-phase locked, but not strict two-phase locked. To run w 2 [x], T 1 must have released its read lock on x before w 2 [x], which means it cannot be strict two-phase locked. Moreover, to be two- phase locked, it must have gotten its write lock on y before it released its read lock on x. Thus, we have the following: rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] wl 1 [y] ru 1 [x] wl 2 [x] w 2 [x] w 1 [y] c 1 wu 1 [y] wl 2 [y] w 2 [y] c 2 ru 2 [x] wu 2 [y] Problem 1 (continued) 3

4 H 3 : r 1 [y] r 1 [x] r 2 [x] w 1 [y] w 2 [y] c 2 c 1 H 3 is two-phase locked, but not strict two-phase locked because T 1 must have released its write lock before w 2 [y] executed. rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] wl 1 [y] w 1 [y] wu 1 [y] wl 2 [y] w 2 [y] c 2 ru 2 [x] wu 2 [y] c 1 ru 1 [x] Problem 1 (continued) 4

5 H 4 : r 1 [y] r 1 [x] r 2 [x] w 2 [x] r 3 [y] w 1 [y] c 1 w 3 [z] c 3 w 2 [y] c 2 H 4 is not two-phase locked. To see why, consider the following prefix of the history: rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] The next operation is w 2 [x]. So as in H 2, T 1 must have released its read lock on x before w 2 [x], so again the next few operations must have been wl 1 [y] ru 1 [x] wl 2 [x] w 2 [x], as in the following expanded prefix. rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] wl 1 [y] ru 1 [x] wl 2 [x] w 2 [x] Problem 1 (continued) 5

6 6 H 4 continued H 4 : r 1 [y] r 1 [x] r 2 [x] w 2 [x] r 3 [y] w 1 [y] c 1 w 3 [z] c 3 w 2 [y] c 2 rl 1 [y] r 1 [y] rl 1 [x] r 1 [x] rl 2 [x] r 2 [x] wl 1 [y] ru 1 [x] wl 2 [x] w 2 [x] The next operation is r 3 [y]. To have executed here, T 3 would have to obtain its lock on y, which requires that T 1 had already released its lock on y, which it could not have done at this point because it hasn’t yet executed w 1 [y]. Nevertheless, this history is SR. We have only the following SG edges: T 1  T 2 because (r 1 [x],w 2 [x]) and (w 1 [y], w 2 [y]) T 3  T 1 because (r 3 [y], w 1 [y]) There’s no cycle in the SG, so the history is serializable as T 3 T 1 T 2. Note that there are no transaction handshakes in the input, so there are none to preserve.

7 Extra credit: Is it possible for a history to be strict two-phase locked but not normally-strict two phase locked? No. To prove it, let H be a strict 2PL history that has been augmented with lock and unlock operations to demonstrate that it’s strict 2PL. We can transform H into a history each of whose lock operations immediately precedes the operation it’s synchronizing, as follows. Suppose that for some operation o i [x] in H, the corresponding lock request ol i [x] does not immediately precede o i [x]. The only constraint that prevents moving ol i [x] to the right in H so that it immediately precedes o i [x] is an unlock operation by T i, since that would break 2PL. However, since H is strict 2PL, all of T i ’s unlock operations follow c i. Therefore, it’s possible to move ol i [x] to the right in H so that it immediately precedes o i [x]. This can be done for all offending lock operations in H, thereby transforming it into a demonstration that H is normally-strict 2PL-ed. 7

8 Problem 2: Yes, a transaction can be involved in multiple deadlocks. Consider the following three sequential transactions: T 1 : r 1 [x] r 1 [y] T 2 : r 2 [x] r 2 [y] T 3 : w 3 [y] w 3 [x] Suppose they start executing as follows: H 1 : r 1 [x] r 2 [x] w 3 [y] So far, T 1 and T 2 each have a read lock on x, and T­ ­3 has a write lock on y. Next, each transaction tries to set a lock for its second operation: r 1 [y], r 2 [y], and w 3 [x]. However, no matter which order the three lock requests are made, none of those lock requests can be granted, because another transaction already owns a conflicting lock. In terms of the waits-for graph, we have: T 1  T 3 because T 1 requests a read lock on y and T 3 owns a write lock on y T 2  T 3 for the same reason as above T 3  T 1 because T 3 requests a write lock on x and T 1 owns a read lock on x T 3  T 2 for the same reason as above. Thus, there are two deadlock cycles in the graph, T 1  T 3  T 1 and T 2  T 3  T 2. 8

9 Since each transaction is sequential, it can only have one blocked operation. It is therefore tempting to say that there could only be one outgoing edge from the transaction in the waits-for graph. But the italicized implication is wrong, because a transaction may issue a write request, thereby waiting for all of the transactions holding a read lock. Therefore, it is waiting for each of those read transactions and has more than one outgoing edge. In the above example T 3 is waiting for both T 1 and T 2 to unlock x. Then T 1 and T 2 each request a lock on y, which causes each of them to deadlock (independently) with T 3. Problem 2 (continued): 9

10 Problem 3 Let’s hand execute each sequence by issuing a lock request for each operation as it arrives: a) H 1 : r 1 [x,y] r 2 [x] w 1 [x] w 2 [z] r 3 [z] r 3 [y] w 3 [y] rl 1 [x,y] r 1 [x,y] rl 2 [x] r 2 [x] {wl 1 [x] is blocked} wl 2 [z] w 2 [z] {T 2 is done so it could have issued commit at this point} c 2 wu 2 [x] wu 2 [z] {now we can set wl 1 [x]} wl 1 [x] w 1 [x] {T 1 is done so it can commit} c 1 ru 1 [y] wu 1 [x] {now there are no locks held so T 3 can execute and commit}. So adding commits to H 1 : H 1 : r 1 [x,y] r 2 [x] w 1 [x] w 2 [z] c 2 c 1 r 3 [z] r 3 [y] w 3 [y] c 3 10

11 b) H 2 : r 1 [x,y] r 2 [x] w 1 [x] r 3 [z] w 2 [z] r 3 [y] w 3 [y] rl 1 [x,y] r 1 [x,y] rl 2 [x] r 2 [x] {w 1 [x] is blocked} rl 3 [z] r 3 [z] {w 2 [z] is blocked} rl 3 [y] r 3 [y] {w 3 [y] is blocked} There’s a deadlock: w 1 [x] is waiting for rl 2 [x], w 2 [z] is waiting for rl 3 [z], and w 3 [y] is waiting for rl 1 [y]. Problem 3 (continued) 11


Download ppt "Assignment 3 -- Solution 1. Problem 1 H 1 : r 1 [y] r 1 [x] r 2 [x] w 1 [y] c 1 w 2 [y] c 2 H 1 is normally-strict two-phase locked: rl 1 [y] r 1 [y]"

Similar presentations


Ads by Google