DB server technology
VSR, CSR, 2PL, TS, TS-Multi
[email protected]
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.
Concurrency Control
Techniques
●
Theoretical:
–
–
●
View-Serializability (VSR)
Conflict-Serializability (CSR)
Practical:
–
–
Two Phase Locking (2PL, 2PL Strict)
Timestamp (TS Single, TS Multi)
3
Concurrency Control
Techniques
All
TS
VSR
2PL
Serial
CSR
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
Definition: a write wi(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 wj(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
Z: w4; r3; r6; r8; w9; w5; r10
X: w4; r2; w3
2
Y: w2; w4
3
8
9
4
6
5
10
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!
B.7 Classify the following schedule w.r.t. the classes
VSR, CSR, 2PL, TS-mono
r1(X) w1(Y) w2(Y) w3(Z) r1(Z) w4(X) r4(Y) w3(X) r5(Y) w5(X)
Solution:
X: r1 w4 w3 w5
Y: w1 w2 r4 r5
Z: w3 r1
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, w4(X) w3(X), are not involved in cycles).
Therefore the schedule is not even in VSR
B.8 Exam 04-07-2006
• Classify the following schedule w.r.t. VSR, CSR, 2PL, Strict 2PL,
TS-mono, TS-multi
r1(X) w1(Y) w2(Y) w3(Z) r1(Z) w4(X) r4(Y) w3(X) r5(Y) w5(X)
3
X: r1 w4 w3 w5
Y: w1 w2 r4 r5
Z: w3 r1
4
1
2
5
There are cycles (1-3, 1-4-3, 1-2-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, w4(X)
w3(X), are not involved in cycles).
10
Will it be TS-multi?
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
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 WTMN(x).
There is a unique global RTM(x)
12
Timestamp Multi-version
●
Rules:
–
–
read(x,ts) is always accepted. A copy xk is
selected for reading such that:
●
If ts > WTMN(x), then k = N
●
Else take k such that WTMk(x) < ts < WTMk+1(x)
write(x,ts):
●
●
If ts < RTM(x) the request is rejected
Else a new version is created (N is incremented)
with WTMN(x) = ts
1
2
3
13
X
R1(x)
Y
Z
RTM
WTM
RTM
WTM
RTM
WTM
1(0)
0
0
0
0
0
W1(y)
0,1
W2(y)
0,1,2
W3(z)
0,3
R1(z)
W4(x)
1(0)
0,4
R4(y)
W3(x)
4(2)
0,3,4
R5(y)
W5(x)
T killed
4
3 killed?? No? Why?
5(2)
0,3,4,5
14
All
?
TS multi
2PL
TS(mono)
VSR
Serial
CSR
A schedule that is TS-multi but NOT VSR?
w1(X) w2(X) r1(X)
15
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
X
Y
notes
1
r1(x)
S1
2
w1(x)
X1
3
w3(x)
4
r2(y)
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
3 has to wait t1 for X
X1
S2
17
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
X
1
r1(x)
S1
2
w1(x)
X1
3
w3(x)
4
r2(y)
5
r3(y)
6
w3(y)
7
c3
8
w1(y)
9
c1
10
r2(x)
11
c2
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
X
1
r1(x)
S1
2
w1(x)
X1
3
w3(x)
4
r2(y)
5
r3(y)
6
w3(y)
7
c3
8
w1(y)
9
c1
10
r2(x)
11
c2
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
X
1
r1(x)
S1
2
w1(x)
X1
X1
3
w3(x)
4
r2(y)
5
r3(y)
6
w3(y)
7
c3
8
w1(y)
9
c1
10
r2(x)
11
c2
Y
notes
X1
X3
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
X
1
r1(x)
S1
2
w1(x)
X1
X1
Y
notes
X1
3
w3(x)
X3
4
r2(y)
5
r3(y)
From this example we can derive
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
X
1
r1(x)
S1
2
w1(x)
X1
3
w3(x)
4
r2(y)
5
r3(y)
6
w3(y)
7
c3
8
w1(y)
9
c1
10
r2(x)
11
c2
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
X
Y
notes
1
r1(x)
S1
2
w1(x)
X1
3
w3(x)
4
r2(y)
5
r3(y)
waiting
6
w3(y)
waiting
7
c3
waiting, can’t commit
8
w1(y)
9
c1
10
r2(x)
11
c2
3 has to wait t1 for X
X1
S2
t1 needs an exclusive lock on Y, t2
does not need it anymore, but it
should lock X before unlocking Y.
24
X
Y
notes
1
r1(x)
S1
2
w1(x)
X1
3
w3(x)
4
r2(y)
5
r3(y)
waiting
6
w3(y)
waiting
7
c3
waiting, can’t commit
8
w1(y)
9
c1
10
r2(x)
11
c2
3 has to wait t1 for X
X1
S2
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.
25
X
Y
notes
1
r1(x)
S1
2
w1(x)
X1
3
w3(x)
4
r2(y)
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
3 has to wait t1 for X
X1
S2
26
t3
t1
t2
There is still a deadlock, the schedule is not 2PL.
27
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
Log Records
Transaction records
System records
Actions performed by
transactions.
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
Log example
30
Reliability primitives
UNDO( Action )
REDO( Action )
• Update and Delete:
• Update and Insert:
– O ← BS
• Insert:
– Remove O
– O ← AS
• Delete:
– Remove O
Idempotence of undo and redo:
UNDO( UNDO( Action ) ) = UNDO( Action )
REDO( REDO( Action ) ) = REDO( Action )
31
Warm Restart
1. UNDO = Most recent checkpoint, REDO = {}
32
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
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
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
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
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
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
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
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
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
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
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
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
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
I.2
With the same
hierarchy:
p1
p2
p3
r1 r2 r3
r4 r5
r6 r7 r8
But the following LOG:
A
B
C
D
b(t1), b(t2), u(t1,r4,b1,a1), u(t1,r2,b2,a2),
E
F
G
H
I
u(t2,r6,b3,a3), u(t2,r3,b4,a4), u(t2,r2,b5,a5), c(t1), c(t2)
47
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
A, B)
p1 r1 r2 r3 p2 r4 r5 p3 r6 r7 r8
no requests
- - - - - - - - - - C) u(t1,r4,b1,a1)
IXL(t1,p2)
ix1
XL(t1,r4)
ix1 x1
D) u(t1,r2,b2,a2)
IXL(t1,p1)
XL(t1,r2)
ix1
ix1
x1
ix1 x1
ix1 x1
E) u(t2,r6,b3,a3)
IXL(t2,p3)
XL(t2,r6)
ix1
ix1
x1
x1
ix1 x1
ix1 x1
ix2
ix2 x2
p1 r1 r2 r3 p2 r4 r5
F) u(t2,r3,b4,a4)
IXL(t2,p1)
XL(t2,r3)
p3 r6 r7 r8
ix1,2
ix1,2
x1
ix1 x1
x1 x2 ix1 x1
ix2 x2
ix2 x2
G) u(t2,r2,b5,a5)
XL(t2,r2)
ix1,2
x1 x2 ix1 x1
ix2 x2
H) c(t1) I c(t2)
t1 did not do the commit, then, if t2 obtained the lock the log
is not generated by a 2PL Strict
To finish t1 needs only the commit, then it can have
unlocked r2 immediately before G): the log is 2PL NON
Strict