Transaction. Primary unit of work Well formed: Sequence of operations between begin and end (commit or abort)

Size: px

Start display at page:

Download "Transaction. Primary unit of work Well formed: Sequence of operations between begin and end (commit or abort)"

Stephanie Henry
6 years ago
Views:

1 Transaction Primary unit of work Well formed: Sequence of operations between begin and end (commit or abort) Concurrency needed in order to start multiple parallel transactions. 1

2 Serial and serializable schedules Serial schedules: the actions of every transaction appear in blocks. A schedule is correct if it produces the same result as a serial schedule: serializable. 2

3 Concurrency Control Techniques Theoretical: View-Serializability (VSR) Conflict-Serializability (CSR) Practical: Two Phase Locking (2PL, 2PL Strict) Timestamp (TS Single, TS Multi) 3

4 Concurrency Control Techniques All VSR CSR TS(mono) 2PL Serial 4

5 View-Serializability VSR Same final writes and reads-from as one of the serial schedules. w0(x) r2(x) r1(x) w2(x) w2(z) w0(x) r1(x) r2(x) w2(x) w2(z) 5

6 Conflict Graph Construction One node for every transaction A directed arc for every conflict: read / write write / write write / read CONFLICTS ARE GENERATED EVEN FOR NON-CONSECUTIVE OPERATIONS 6

7 The following schedule is in VSR. Classify it wrt VSR, CSR r1(x), w2(x), r1(z), w1(y), r3(x), r4(x), w3(z), w2(y), r3(y), w4(x), w4(y)

8 r1(x), w2(x), r1(z), w1(y), r3(x), r4(x), w3(z), w2(y), r3(y), w4(x), w4(y) X: r1, w2, r3, r4, w4 Y: w1, w2, r3, w4 Z: r1, w3 Conflict graph:

9 Definition: a write w i (X) is said to be blind if it is not the last action of resource X and the following action on X is a write w j (X) Property: each schedule S VSR and S CSR has, in its conflict graph, cycles of arcs due to couples of blind writes. These can be swapped without modifying the readsfrom and final write relationships. Once the graph is acyclic it is possible to find a serial schedule view-equivalent to the initial one. 9

10 Concurrency Control Hierarchical lock and Update lock A 2PL system receives these requests from 3 transactions, each requesting the minimum level of lock in order to execute: r 1 (t1) r 2 (t1) r 3 (t1) w 1 (t1) r 2 (t5) w 3 (t1) Show the behavior of the system (order of requests, order of actual execution, their result) in two different scenarios: (1) without update-lock on tuples (2) with update-lock on tuples Also show the behavior with the following page-tuple hierarchy: P1(t1,t2,t3), P2(t4,t5,t6)

11 (Scenario 1) Without update lock, all transactions eagerly acquire their SL on t1: r 1 (t1) r 2 (t1) r 3 (t1) w 1 (t1) r 2 (t5) w 3 (t1) SL 1 (t1) r 1 (t1) SL 2 (t1) r 2 (t1) SL 3 (t1) r 3 (t1) [T3 and T1 cannot upgrade their locks and wait for the resource to be released] SL 2 (t5) r 2 (t5) rel(sl 2 (t5)) rel(sl 2 (t1)) [T2 commits, but T1 and T3 are in deadlock]

12 (Scenario 2) With update-lock on tuples, transactions T1 and T3 are forced to acquire update locks on t1, while T2 can request a read-lock (because its next write occurs on a different resource) UL 1 (t1) r 1 (t1) SL 2 (t1) r 2 (t1) [T3 and T1 have to wait, as t1 is locked] SL 2 (t5) r 2 (t5) rel(sl 2 (t5)) rel(sl 2 (t1)) [now T1 can continue] XL 1 (t1) w 1 (t1) rel(xl 1 (t1)) [now T3 can start ] UL 3 (t1) r 3 (t1) XL 3 (t1) w 3 (t1) rel(xl 3 (t1)) Locks marked in blue are lock upgrades, and the corresponding rel(.) also releases the previously acquired weaker lock.

13 In order to consider the Update Lock on hierarchical resources we need to extend the notion of intention to the case of UL, introducing the notion of INTENTION OF UPDATE LOCK, regulated by the following table

14 P1(t1,t2,t3), P2(t4,t5,t6) r 1 (t1) r 2 (t1) r 3 (t1) w 1 (t1) r 2 (t5) w 3 (t1) (Scenario 2) With update-lock on tuples, transactions T1 and T3 are forced to acquire update locks on t1, while T2 can request a read-lock (because its next write occurs on a different resource) IUL 1 (P1) UL 1 (t1) r 1 (t1) ISL 2 (P1) SL 2 (t1) r 2 (t1) [T3 and T1 have to wait, as t1 is locked] ISL 2 (P2) SL 2 (t5) r 2 (t5) rel(sl 2 (t5)) rel(isl 2 (P2)) rel(sl 2 (t1)) rel(isl 2 (P1)) [now T1 can continue] IXL 1 (P1) XL 1 (t1) w 1 (t1) rel(xl 1 (t1)) rel(ixl 1 (P1)) [now T3 can start ] IUL 3 (P1) UL 3 (t1) r 3 (t1) IXL 3 (P1) XL 3 (t1) w 3 (t1) rel(xl 3 (t1)) rel(ixl 3 (P1)) (Scenario 1) Without update lock, all transactions eagerly acquire their SL on t1: ISL 1 (P1) SL 1 (t1) r 1 (t1) ISL 2 (P1) SL 2 (t1) r 2 (t1) ISL 3 (P1) SL 3 (t1) r 3 (t1) [T3 and T1 cannot upgrade their locks] ISL 2 (P2) SL 2 (t5) r 2 (t5) rel(sl 2 (t5)) rel(isl 2 (P2)) rel(sl 2 (t1)) rel(isl 2 (P1)) [T2 commits, but T1 and T3 are in deadlock]

15 The following schedule is in VSR. Classify it wrt CSR, TS mono, TS multi, 2PL Strict r1(x), w2(x), r1(z), w1(y), r3(x), r4(x), w3(z), w2(y), r3(y), w4(x), w4(y)

16 Conflict graph:

17 For 2PL strict we assume that all transactions commit and release all locks immediatly after their last operation (this is the least restrictive option), and check if acquisition can occur increasingly.

18 In details... It is clear at once that T 1 must release the SL on X before instant 2 (for T 2 to acquire XL on it), but this is not compatible with 2PL Strict, as the last operation of T 1 occurs at instant 4. One may also observe that T 2 must release SL on X before instant 5 (for T 3 to acquire SL on it), but the last operation of T 2 is at instant 8. From the conflict graph, that is acyclic, we know the schedule to be in CSR, and the only serial schedule view equivalent is T 1,T 2,T 3,T 4. Eventually, it is easy to observe that the schedule is both in TS mono- and TS multi-versioned, even without simulating the evolution of RTM and WTM counters. Transaction pedices, indeed, occur in strictly increasing order in the operations relative to each resource, so that no operation can be rejected by the TS rules.

19 Timestamp Mono-version The scheduler has two counters: RTM(x) and WTM(x) for each object The scheduler receives read and write requests with timestamps: read(x,ts): If ts < WTM(x) the request is rejected and the transaction killed Else, the request is granted and RTM(x) is set to max(rtm(x), ts) write(x,ts): If ts < WTM(x) or ts < RTM(x) the request is rejected and the transaction killed Else, the request is granted and WTM(x) is set to ts Many transactions are killed To work w/o the commit-projection hypothesis, it needs to "buffer" write operations until commit, which introduces waits 19

20 Timestamp Multi-version Rules: read(x,ts) is always accepted. A copy x k is selected for reading such that: If ts > WTM N (x), then k = N Else take k such that WTM k (x) < ts < WTM k+1 (x) write(x,ts): If ts < RTM(x) the request is rejected Else a new version is created (N is incremented) with WTM N (x) = ts 20

21 (ctrl-z) n The following schedule belongs to the class TS 2-versions but does not belong to TS-mono-version: r 2 (X) w 2 (X) r 1 (X) Extend the diagram of the classes VSR, CSR, 2PL, TS-mono with the sets TS 2-versions, TS 3-versions. Show an example of schedule that belongs to TS-3 but not to TS-2. 21

22 (ctrl-z) n If we have even only one version of the data previous to the most recent one, we can infringe the reads-from principle, thus making the classes TS-n not strictly included in the VSR set (for n > 1). For example the schedule: w 1 w 2 r 1 is not serializable, but is accepted by a system that uses TS with more than one version. Moreover, as the number of available versions increases, also the number of accepted schedules grows. The schedule w 1 w 2 w 3 r 1 belongs to TS-3 but not to TS-2. In general, the schedule w 1 w 2 w 3... w n-1 w n r 1 belongs to TS-n but not to TS-(n-1). 22

23 TS-n... TS-3 TS-2 VSR CSR TS(mon o) 2PL Seria l 23

24 ACID Transactions Concurrency Serial Schedule VSR, CSR, 2PL, 2PL Strict, TS, TS-Multi Reliability System Log and Dump Warm/Cold restart Guarantees: I: Isolation Guarantees: A: Atomicity D: Durability C: Consistency is guaranteed at query compile time 24

25 Log Records Transaction records Actions performed by transactions. System records Actions performed by the reliability controller. Begin (T) Insert (T, O, AS) Delete (T, O, BS) Update (T, O, BS, AS) Commit (T) Abort (T) Checkpoint (T1, T2, ) Dump () T = Transaction, O = Object, BS = Before State, AS = After State 25

26 Reliability primitives UNDO( Action ) REDO( Action ) Update and Delete: O BS Insert: Remove O Update and Insert: O AS Delete: Remove O Idempotence of undo and redo: UNDO( UNDO( Action ) ) = UNDO( Action ) REDO( REDO( Action ) ) = REDO( Action ) 26

27 Warm Restart 1. UNDO = Most recent checkpoint, REDO = {} 2. Starting from the most recent checkpoint: Begin(T): UNDO += T Commit(T): UNDO -= T, REDO += T 3. Trace back the log and undo all the actions of the transaction in the UNDO set. 4. Trace forward the log and redo all the actions of the transactions in the REDO set. 27

28 Example: describe the warm restart, indicating the progressive construction of the sets UNDO e REDO and the recovery actions, given the following situation on the log: Dump, b(t1), b(t2), b(t3), i(t1,o1,a1), d(t2,o2,b2), b(t4), u(t4,o3,b3,a3), u(t1,o4,b4,a4), c(t2), ckpt(t1,t3,t4), b(t5), b(t6), u(t5,o5,b5,a5), a(t3), ckpt(t1,t4,t5,t6), b(t7), a(t4), u(t7,o6,b6,a6), u(t6,o3,b7,a7), b(t8), a(t7), failure 28

29 Distributed deadlock Apply the distributed deadlock detection algorithm to the following wait-for conditions: Node 1: E2 t1; t1 t2; t2 E3; E4 t3; t3 t1 Node 2: E3 t4; t4 t5; t5 t1; t1 E1; t6 E3 Node 3: E2 t6; t6 t7; t7 E4; E1 t2; t2 t7; t4 E2 Node 4: E3 t7; t7 t3; t3 E1 29

30 t i t j indicates a local waiting (t i waits for the unlock of the resource locked by t j ) t i E n indicates that t i waits for the termination of the execution of a subtransaction t? on the node n (synchronous invocation) E m t i indicates that t i has been invoked synchronously by a transaction t? active on the node m 30

31 Any waiting condition where a subtransaction t, activated by a remote DBMS i on the node m, is waiting for a lock to be released by another transaction t, which in j turn waits for the termination of a remote sub-transaction invoked on a DBMS on node n. The waiting situation is summarized by the following wait sequence: E m t i t j E n 31

32 The algorithm is distributed. Every instance (executed by a node) communicates to other instances of the same algorithm the waiting sequences: E m t i t j E n Messages are sent only ahead. That is, towards the nodes where the sub-transaction for which t is j waiting was activated. Also, the message is sent only if (for example) i>j 32

33 We simulate the execution asynchronous and distributed of the deadlock detection algorithm. Each node decides to send detected waiting condition (from remote to remote): E m t i t m t n... t p t j E n is translated into the message: E m t i t j E n To be sent to node n, if ad only if i > j 33

34 NODE 1 NODE 2 NODE 3 NODE 4 2 E 3 6 E 3 2 E 1 1 E E 4 3 E 1 3 E E 3 6 E 1 4 E 2 E 2 7 E 3 E 4 ->t 3 ->t 2 ->E 3 to be sent to node 3 E 3 ->t 4 ->t 1 ->E 1 to be sent to node 1 Nothing to be sent E 3 ->t 7 ->t 3 ->E 1 to be sent to node 1 34

35 NODE 1 NODE 2 NODE 3 NODE 4 2 E 3 6 E 3 2 E 1 1 E 3 E E 4 3 E 1 3 E E 1 4 E 2 E 2 7 E 3 7 E 3 4 E 3 3 E 4 E 3 ->t 7 ->t 2 ->E 3 to be sent to node 3 Nothing to be sent Nothing to be sent Nothing to be sent 35

36 NODE 1 NODE 2 NODE 3 NODE 4 2 E 3 6 E 3 2 E 1 1 E 2 4 E 3 7 E 4 3 E 1 3 E E E 2 E 2 7 E 3 4 E 3 7 E 3 3 E 4 3 E 4 Cycle 2-7 Deadlock 36

37 Z.1 Determine if the following schedule is compatible with 2PL Strict, 2PL or non-2pl. r1(x) w1(x) r2(z) r1(y) w1(y) r2(x) w2(x) w2(z) We SUPPOSE that the commits are performed immediately after the transaction last operation r1(x) w1(x) r2(z) r1(y) w1(y) c1 r2(x) w2(x) w2(z) c2

38 1 r1(x) S 1 2 w1(x) X 1 X Y Z notes 3 r2(z) X 1 S 2 4 r1(y) X 1 S 1 S 2 5 w1(y) X 1 X 1 S 2 6 c1 X 1 X 1 S 2 7 r2(x) S 2 S 2 8 w2(x) X 2 S 2 9 w2(z) X 2 X 2 10 c2 X 2 X 2 No incompatibilities, the schedule is 2PL Strict compatible (and also 2PL).

39 Z.2 Determine if the following schedule is compatible with 2PL Strict, 2PL or non-2pl. r1(x) w1(x) w3(x) r2(y) r3(y) w3(y) w1(y) r2(x) We SUPPOSE that the commits are performed immediately after the transaction last operation r1(x) w1(x) w3(x) r2(y) r3(y) w3(y) c3 w1(y) c1 r2(x) c2

40 X Y notes 1 r1(x) S 1 2 w1(x) X 1 3 w3(x) 3 has to wait t1 for X 4 r2(y) X 1 S 2 5 r3(y) waiting 6 w3(y) waiting 7 c3 waiting, can t commit 8 w1(y) 1 has to wait t2 for Y 9 c1 waiting, can t commit 10 r2(x) 2 has to wait t1 for X 11 c2 waiting, can t commit

41 There is a DEADLOCK between t1 and t2. t3 t1 t2 The schedule is not compatible with 2PL Strict. We can remove the strictness and check if it s 2PL. (A transaction can unlock resources before the commit, but cannot acquire other locks after the first unlock).

42 1 r1(x) S 1 2 w1(x) X 1 3 w3(x) 4 r2(y) 5 r3(y) 6 w3(y) 7 c3 8 w1(y) 9 c1 10 r2(x) 11 c2 X Y notes In order to let t3 lock X, t1 should unlock it before. Because of the 2PL rule (after the first unlock the transaction cannot lock any other resource), we should try to anticipate all the locks for t1 before the first unlock.

43 1 r1(x) S 1 2 w1(x) X 1 3 w3(x) 4 r2(y) 5 r3(y) 6 w3(y) 7 c3 8 w1(y) 9 c1 10 r2(x) 11 c2 X Y notes The only other action for t1 is w1(y). We should move its lock upwards, to be able to unlock X. Without anticipating the lock, in fact, t1 needs to unlock X and then lock Y, which is not possible for the 2PL rule.

44 1 r1(x) S 1 2 w1(x) X 1 X 1 X 1 3 w3(x) X 3 4 r2(y) X Y notes 5 r3(y) 6 w3(y) 7 c3 8 w1(y) 9 c1 10 r2(x) Now it s possible for t3 to lock X. But t1 cannot unlock Y until w1(y) (instant 8). This would conflict with the actions r2(y), r3(y) and w3(y) (instants 4, 5, 6). So this solution is not feasible. 11 c2

45 1 r1(x) S 1 2 w1(x) X 1 X 1 X 1 3 w3(x) X 3 X Y notes 4 r2(y) 5 r3(y) 6 w3(y) 7 c3 8 w1(y) 9 c1 10 r2(x) 11 c2 From this example we can derive that: We can anticipate the locks/unlocks of the action A (instant M) to the instant N, only if A is not in conflict with any other action X between N and M. Otherwise we would generate more conflicts more waiting states.

46 1 r1(x) S 1 2 w1(x) X 1 3 w3(x) 4 r2(y) 5 r3(y) 6 w3(y) 7 c3 8 w1(y) 9 c1 10 r2(x) 11 c2 X Y notes We could anticipate the lock of Y and unlock of X for t1 before 7, but not before 6 (it would generate a conflict). This doesn t solve the waiting state, so w3(x) has to wait.

47 1 r1(x) S 1 2 w1(x) X 1 X Y notes 3 w3(x) 3 has to wait t1 for X 4 r2(y) X 1 S 2 5 r3(y) waiting 6 w3(y) waiting 7 c3 waiting, can t commit 8 w1(y) 9 c1 10 r2(x) 11 c2 t1 needs an exclusive lock on Y, t2 does not need it anymore, but it should lock X before unlocking Y.

48 1 r1(x) S 1 2 w1(x) X 1 X Y notes 3 w3(x) 3 has to wait t1 for X 4 r2(y) X 1 S 2 5 r3(y) waiting 6 w3(y) waiting 7 c3 waiting, can t commit 8 w1(y) 9 c1 10 r2(x) 11 c2 Unfortunately, the resource X is locked by t1, so it cannot be locked by t2. And t1 cannot release it otherwise it loses the ability to lock Y.

49 X Y notes 1 r1(x) S 1 2 w1(x) X 1 3 w3(x) 3 has to wait t1 for X 4 r2(y) X 1 S 2 5 r3(y) waiting 6 w3(y) waiting 7 c3 waiting, can t commit 8 w1(y) 1 has to wait t2 for Y 9 c1 waiting, can t commit 10 r2(x) 2 has to wait t1 for X 11 c2 waiting, can t commit

50 t3 t1 t2 There is still a deadlock, the schedule is not 2PL.

VSR, CSR, 2PL, TS, TS-Multi

DB server technology VSR, CSR, 2PL, TS, TS-Multi simone.mutti@unibg.it Transaction Primary unit of work Well formed: Sequence of operations between begin and end (commit or abort) Concurrency needed in