Download - More Transaction Management
![Page 1: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/1.jpg)
1
More Transaction Management
Concurrency control and recovery
Resolving deadlocksLogical logging
Source: slides by Hector Garcia-Molina
![Page 2: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/2.jpg)
2
Example: Tj Ti
wj(A) ri(A) Commit Ti
Abort Tj
Concurrency control & recovery
……
…
……
… Cascading rollback (Bad!)
![Page 3: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/3.jpg)
3
Schedule is conflict serializable:Tj Ti
But not recoverable
![Page 4: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/4.jpg)
4
Need to make “final" decision for each transaction: commit decision - system guarantees
transaction will or has completed, no matter what
abort decision - system guarantees transaction will or has been rolled back
(has no effect)
![Page 5: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/5.jpg)
5
To model this, two new actions: Ci - transaction Ti commits Ai - transaction Ti aborts
Each transaction Ti has exactly one, either Ci or Ai
Every read and write of Ti precedes the Ci (or Ai)
![Page 6: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/6.jpg)
6
...
...
...
...
Back to example:
Tj Ti
Wj(A)ri(A)
Ci can we commit
here?
![Page 7: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/7.jpg)
7
Definition
Ti reads from Tj in S (denoted Tj S Ti) if
1. there is a write wj(A) in S that is followed by a read ri(A) in S
2. there is no abort of Tj in S before the ri(A) in S
3. if there is a write to A in S between wj(A) and ri(A) by another transaction Tk, then Tk aborts before the ri(A)
![Page 8: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/8.jpg)
8
Definition
Schedule S is recoverable if whenever Ti reads from another transaction Tj, Ti does not commit until after Tj commits.
![Page 9: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/9.jpg)
9
How to achieve recoverable schedules?
![Page 10: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/10.jpg)
10
With 2PL, hold write locks until transaction commits (strict 2PL) Tj Ti
Wj(A)
Cj
uj(A)ri(A)
...
...
...
...
...
...
...
![Page 11: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/11.jpg)
11
S is recoverable if each transaction commits only after all transactions from which it read have committed.
S avoids cascading rollback if each transaction may read only those values written by committed transactions.
![Page 12: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/12.jpg)
12
S is strict if each transaction may read and write only items previously written by committed transactions.
Avoids cascading rollback
RC
ACR
ST SERIAL
![Page 13: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/13.jpg)
13
Where are serializable schedules?
Avoids cascading rollback
RC
ACR
ST SERIAL
SERIALIZABLE
![Page 14: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/14.jpg)
14
Examples
Recoverable: w1(A) w1(B) w2(A) r2(B) c1 c2
Avoids Cascading Rollback: w1(A) w1(B) w2(A) c1 r2(B) c2
Strict: w1(A) w1(B) c1 w2(A) r2(B) c2
![Page 15: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/15.jpg)
15
More Examples
SERIALIZABLE
Avoids cascading rollback
RC
ACR
ST SERIAL
w1(A) w1(B) w2(A) r2(B) c2 c1
w2(A)w1(B)w1(A)r2(B)c1
c2
![Page 16: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/16.jpg)
16
Deadlocks
Detection Wait-for graph
Prevention Resource ordering Timeout Wait-die Wound-wait
![Page 17: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/17.jpg)
17
Deadlock Detection
Build Wait-For graph Use lock table structures Build incrementally or periodically When cycle found, rollback victim
T1
T3
T2
T6
T5
T4T7
![Page 18: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/18.jpg)
18
Resource Ordering
Order all elements A1, A2, …, An
Each transaction must acquire locks on elements in this order (i.e., T cannot lock Aj before Ai if j > i)
Problem : Ordered lock requests not realistic in most cases
![Page 19: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/19.jpg)
19
Timeout
If transaction waits more than L sec., roll it back!
Simple scheme Hard to select L
![Page 20: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/20.jpg)
20
Wait-die
Each transaction Ti is given a timestamp when it starts, denoted ts(Ti)
Suppose Ti requests a lock currently held by Tj
if ts(Ti)< ts(Tj) then Ti waits for Tj (older waits for
younger) else Ti dies (aborts) (younger dies)
If Ti dies then it later restarts with the same timestamp
![Page 21: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/21.jpg)
21
T1
(ts =10)
T2
(ts =20)
T3
(ts =25)
wait
wait
Example:
wait?No.
![Page 22: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/22.jpg)
22
Wound-wait Each transaction Ti is given a timestamp
when it starts, denoted ts(Ti) Suppose Ti requests a lock currently held
by Tj
If ts(Ti)< ts(Tj) then Ti wounds Tj (younger yields lock to
older) else Ti waits (younger waits for older)
“Wound”: Tj rolls back and gives lock to Ti
If Tj dies then later it restarts with the same timestamp
![Page 23: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/23.jpg)
23
T1
(ts =25)
T2
(ts =20)
T3
(ts =10)
wait
wait
Example:
wait?
(Note that timestamps are different than in previous example)
No.
![Page 24: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/24.jpg)
24
Comparing Deadlock Management Schemes
Wait-die and Wound-wait ensure no starvation (unlike the others)
Wait-die tends to roll back more transactions than Wound-wait but they tend to have done less work
Wait-die and Wound-wait are easier to implement than waits-for graph
Waits-for graph technique only aborts transactions if there really is a deadlock (unlike the others)
![Page 25: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/25.jpg)
25
Managing Rollbacks Using Locking
What are we really locking?
![Page 26: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/26.jpg)
26
Example:
Ti
Read record r1
Read record r1 do record
lockingModify record r3
...
...
...
...
![Page 27: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/27.jpg)
27
But underneath:
Disk
pages
R3
R1
R2
record id
If we lock all
data involved in read
of R1, we may prevent
an update to R2
(which may require
reorganization within
block)
![Page 28: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/28.jpg)
28
Solution: view DB at two levels
Top level: record actions record locks undo/redo actions —
logical
e.g., Insert record(X,Y,Z) Redo: insert(X,Y,Z) Undo: delete
Low level: deal with physical details
![Page 29: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/29.jpg)
29
Note: undo does not return physical DB to original state; only same logical state
e.g., Insert R3 Undo (delete R3)
R1 R1R2
R1R2
R2R3
![Page 30: More Transaction Management](https://reader036.vdocuments.net/reader036/viewer/2022062410/56815a88550346895dc7fc41/html5/thumbnails/30.jpg)
30
Logging Logical Actions
Logical action typically span one block
Undo/redo log entry specifies undo/redo logical action
• Challenge: making actions idempotent•Example (bad): redo insert
key inserted multiple times!