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

Size: px

Start display at page:

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

Marjorie Barton
6 years ago
Views:

1 DB server technology VSR, CSR, 2PL, TS, TS-Multi

2 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.

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 2PL Serial

5 B.4 Classify the following schedule: w4(x) r2(x) w2(y) w4(y) w3(x) w4(z) r3(z) r6(z) r8(z) w9(z) w5(z) r10(z) 5

6 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. 6

7 Z: w4; r3; r6; r8; w9; w5; r10 X: w4; r2; w3 Y: w2; w The graph is cyclic (4, 2): the schedule is not CSR. It is neither VSR (2 and 4 are not serializable: r2(x) reads-from w4(x), and w4(y) is a final write) and there are no couples of blind writes!

8 B.7 Classify the following schedule w.r.t. the classes VSR, CSR, 2PL, TS-mono r 1 (X) w 1 (Y) w 2 (Y) w 3 (Z) r 1 (Z) w 4 (X) r 4 (Y) w 3 (X) r 5 (Y) w 5 (X)

9 Solution: X: r 1 w 4 w 3 w 5 Y: w 1 w 2 r 4 r 5 Z: w 3 r 1 Cyclic conflict graph -> Not in CSR, therefore not even in 2PL or TS-mono. Also, no CSR schedule that is VSR-equivalent exists (the only two blind writes, w 4 (X) w 3 (X), are not involved in cycles). Therefore the schedule is not even in VSR

10 B.8 Exam Classify the following schedule w.r.t. VSR, CSR, 2PL, Strict 2PL, TS-mono, TS-multi r 1 (X) w 1 (Y) w 2 (Y) w 3 (Z) r 1 (Z) w 4 (X) r 4 (Y) w 3 (X) r 5 (Y) w 5 (X) 3 4 X: r 1 w 4 w 3 w 5 Y: w 1 w 2 r 4 r Z: w 3 r 1 5 There are cycles (1-3, 1-4-3, ). It is not CSR, not 2PL, not TS mono. Not even VSR: T1 and T3 are not serializable (the only two blind writes, w 4 (X) w 3 (X), are not involved in cycles). 10 Will it be TS-multi?

11 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 11

12 Timestamp Multi-version Idea: writes generate new copies, reads access the "right" copy The one they would see if serially executed in timestamp order Reads are always accepted Writes generate new copies, each one with a new WTM. Each object x always has N>1 active copies with WTM N (x). There is a unique global RTM(x) 12

13 Rules: Timestamp Multi-version read(x,ts) is always accepted. A copy x k is selected for reading such that: If ts > WTMN (x), then k = N Else take k such that WTMk (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

14 X Y Z RTM WTM RTM WTM RTM WTM T killed R1(x) 1(0) W1(y) 0,1 W2(y) 0,1,2 W3(z) 0,3 R1(z) 1(0) W4(x) 0,4 R4(y) 4(2) W3(x) 0,3,4 4 3 killed?? No? Why? R5(y) 5(2) W5(x) 0,3,4,5 14

15 ? TS multi All VSR CSR TS(mono) 2PL Serial A schedule that is TS-multi but NOT VSR? w1(x) w2(x) r1(x) 15

16 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 16

17 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 17

18 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). 18

19 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. 19

20 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. 20

21 1 r1(x) S 1 2 w1(x) X 1 X 1 X 1 X Y notes 3 w3(x) X 3 4 r2(y) 5 r3(y) 6 w3(y) 7 c3 8 w1(y) 9 c1 10 r2(x) 11 c2 Now it s possible for t3 to lock X. But t3 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. 21

22 1 r1(x) S 1 2 w1(x) X 1 X 1 X 1 X Y notes 3 w3(x) X 3 4 r2(y) From this example we can derive 5 r3(y) that: 6 w3(y) 7 c3 8 w1(y) 9 c1 10 r2(x) 11 c2 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. 22

23 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. 23

24 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. 24

25 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) Unfortunately, the resource X is 9 c1 locked by t1, so it cannot be locked by t2. 10 r2(x) And t1 cannot release it otherwise it 11 c2 loses the ability to lock Y. 25

26 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 26

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

28 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 28

29 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 29

30 Log example 30

31 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 ) 31

32 Warm Restart 1. UNDO = Most recent checkpoint, REDO = {} 32

33 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 33

34 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. 34

35 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. 35

36 F.1 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 36

37 Trace back the log until the most recent checkpoint is reached and initialise UNDO and REDO sets 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 UNDO={t1,t4,t5,t6} REDO={} 37

38 The log is then traced forward, adding to the UNDO set all the transactions with a begin record, and moving from UNDO to REDO all the transactions with a commit ckpt(t1,t4,t5,t6), b(t7), a(t4), u(t7,o6,b6,a6), u(t6,o3,b7,a7), b(t8), a(t7), failure UNDO={t1,t4,t5,t6,t7,t8} REDO={} 38

39 The log is traced back undoing all the transactions in the UNDO set (with compensating actions), until the first action of the oldest transaction is reached UNDO={t1,t4,t5,t6,t7,t8} REDO={} 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 Actions: o3=b7 o6=b6 o5=b5 o4=b4 o3=b3 delete(o1) 39

40 Finally, the REDO actions are applied in the order in which they are recorded in the log. In this exercise REDO set is empty UNDO={t1,t4,t5,t6,t7,t8} REDO={} 40

41 41

42 F.2 Describe the warm restart, indicating the progressive building of the sets UNDO e RED, given the following situation on the log: Dump, b(t1), u(t1,o1,b1,a1), b(t2), b(t3), u(t3,o3,a3,b3), i(t2,o2,a2), c(t2), ckpt(t1,t3), c(t3), b(t4), u(t4,o2,b4,a4), u(t4,o3,b5,a5), b(t5), i(t5,o6,a6), a(t1), c(t4), u(t5,o7,b7,a7), d(t5,o1,b8), failure 42

43 Trace back the log until the most recent checkpoint is reached and initialise UNDO and REDO sets Dump, b(t1), u(t1,o1,b1,a1), b(t2), b(t3), u(t3,o3,b3,a3), i(t2,o2,a2), c(t2), ckpt(t1,t3), c(t3), b(t4), u(t4,o2,b4,a4), u(t4,o3,b5,a5), b(t5), i(t5,o6,a6), a(t1), c(t4), u(t5,o7,b7,a7), d(t5,o1,b8), failure UNDO={t1,t3} REDO={} 43

44 The log is traced forward, adding to the UNDO all the transactions with a begin, and moving from UNDO to REDO all the transactions with a commit ckpt(t1,t3), c(t3), b(t4), u(t4,o2,b4,a4), u(t4,o3,b5,a5), b(t5), i(t5,o6,a6), a(t1), c(t4), u(t5,o7,b7,a7), d(t5,o1,b8), failure UNDO={t1,t3} UNDO={t1} UNDO={t1,t4} UNDO={t1,t4,t5} REDO={} REDO={t3} REDO={t3} REDO={t3} UNDO={t1,t5} REDO={t3,t4} 44

45 Cold Restart 1. Restore deteriorated objects from the most recent system DUMP. 2. Trace forward the log from the most recent system dump and redo all the actions affecting deteriorated objects. 3. Perform a warm restart. 45

46 Conflicts in Hierarchical Locks Resource state Request ISL IXL SL SIXL XL ISL OK OK OK OK No IXL OK OK No No No SL OK No OK No No SIXL OK No No No No XL No No No No No 46

47 I.2 p1 p2 p3 With the same hierarchy: r1 r2 r3 r4 r5 r6 r7 r8 But the following LOG: A B C D b(t 1 ), b(t 2 ), u(t 1,r4,b1,a1), u(t 1,r2,b2,a2), E F G H I u(t 2,r6,b3,a3), u(t 2,r3,b4,a4), u(t 2,r2,b5,a5), c(t 1 ), c(t 2 ) 47

48 Is it possible that the log has been obtained from a system implementing a Strict-2PL concurrency control policy with hierachical locking? It is necessary to trace the log and lock each resource immediately before the actions and unlock it only after the commit (or the abort). We use a table of resources to verify the compatibility between the requests and the state of the resources. 48

49 A, B) p1 r1 r2 r3 p2 r4 r5 p3 r6 r7 r8 no requests C) u(t 1,r4,b1,a1) IXL(t 1,p2) ix 1 XL(t 1,r4) ix 1 x 1 D) u(t 1,r2,b2,a2) IXL(t 1,p1) ix 1 ix 1 x 1 XL(t 1,r2) ix 1 x 1 ix 1 x 1 E) u(t 2,r6,b3,a3) IXL(t 2,p3) ix 1 x 1 ix 1 x 1 ix 2 XL(t 2,r6) ix 1 x 1 ix 1 x 1 ix 2 x 2

50 p1 r1 r2 r3 p2 r4 r5 p3 r6 r7 r8 F) u(t 2,r3,b4,a4) IXL(t 2,p1) ix 1,2 x 1 ix 1 x 1 ix 2 x 2 XL(t 2,r3) ix 1,2 x 1 x 2 ix 1 x 1 ix 2 x 2 G) u(t 2,r2,b5,a5) XL(t 2,r2) ix 1,2 x 1 x 2 ix 1 x 1 ix 2 x 2 H) c(t1) I c(t2) t 1 did not do the commit, then, if t 2 obtained the lock the log is not generated by a 2PL Strict To finish t 1 needs only the commit, then it can have unlocked r2 immediately before G): the log is 2PL NON Strict

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

Transaction. Primary unit of work Well formed: Sequence of operations between begin and end (commit or abort) 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 Serial and serializable