![Page 1: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/1.jpg)
DBMS2001 Notes 9: Transaction Processing
1
Principles of Database Management Systems
9: More on Transaction Processing
Pekka Kilpeläinen(Partially based on Stanford CS245 slide originals by Hector Garcia-Molina, Jeff
Ullman and Jennifer Widom)
![Page 2: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/2.jpg)
DBMS2001 Notes 9: Transaction Processing
2
Topics to discuss: [from Chapter 10]
• "Dirty reads" and cascading rollback– not solved by recovery (logging) or
serializability (locking) techniques alone– How to avoid
• Transaction isolation in practice• Deadlocks
– Detection – Prevention
![Page 3: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/3.jpg)
DBMS2001 Notes 9: Transaction Processing
3
Problem of Uncommitted Data
• Recall:– logging methods provide reconstructing
the DB to reflect the result of committed transactions
– locking (or validation) methods provide serializability of transactions
• Problem yet uncovered: "dirty data"– data written by an uncommitted transaction
(to buffers or to disk)– may lead to inconsistency, if read by others
![Page 4: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/4.jpg)
DBMS2001 Notes 9: Transaction Processing
4
Example (“dirty read”)
T1 T2 25 25
l1(A); r1(A);A:=A+100; w1(A); l1(B); u1(A)
l2(A); r2(A)A:=A*2; w2(A); l2(B); [Denied]
r1(B); Abort; u1(B); l2(B); u2(A); r2(B)B:=B*2; w2(B);u2(B)
A B
Constraint: A=B
125
250
50
Constraint violation! 250 50
Assume 2PL with X-locks
![Page 5: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/5.jpg)
DBMS2001 Notes 9: Transaction Processing
5
What's the Problem?
• 2PL (as above) ensures correctness if transactions complete But data written by an incomplete (and later aborted) transaction T may correspond to an inconsistent DB
• May require cascading rollback:– Transactions U that have read data written by an
aborted T are rolled back (cancelling their effects on DB using log)
• Transactions V that have read data written by U are rolled back …
– Transactions W that have … are rolled back …
– Expensive, and should be avoided
![Page 6: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/6.jpg)
DBMS2001 Notes 9: Transaction Processing
6
release write locks only after commit/abort
Ti Tj _ . . . . . .Wi(A) . . . . . .
Commitui(A)
rj(A)
• Clearly prevents Tj form reading dirty data, but …
How to avoid cascading rollbacks?
![Page 7: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/7.jpg)
DBMS2001 Notes 9: Transaction Processing
7
• If <Ti, COMMIT> not found on disk, recovery from a system failure cancels updates by Ti data read by Tj becomes dirty– Two solutions:
• Strict locking – release T's write locks only after its
COMMIT/ABORT record flushed to disk
• Group commit – release write locks only after commit/abort– flush log records to disk in the order they
were created (immediate flushing of COMMIT-records not required)
![Page 8: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/8.jpg)
DBMS2001 Notes 9: Transaction Processing
8
Recovery with group commit
<T1, A , 10, 20>...
<T1, COMMIT>...
<T2, A , 20, 30>...
<T2, COMMIT>
LOG: If the log ends at …
1) both T1 and T2 cancelled; OK
2) T2 did not read uncommitted data; OK(and it is cancelled)
3) T2 did not read uncommitted data; OK
![Page 9: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/9.jpg)
DBMS2001 Notes 9: Transaction Processing
9
Avoiding cascading rollbacks with validation
• No change!– Only committed transactions write
(to buffer and to disk) there is no dirty data
![Page 10: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/10.jpg)
DBMS2001 Notes 9: Transaction Processing
10
Transaction Isolation in Practise• SQL2 (SQL-99) does not automatically
require serializability• Transaction programmer may specify
degree of concurrency control through "isolation levels”:set transaction isolation level [
read uncommitted | read committed | repeatable read | serializable ]
![Page 11: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/11.jpg)
DBMS2001 Notes 9: Transaction Processing
11
SQL isolation levels (from weakest to strongest):• read uncommitted
– no updates allowed; may read dirty data
• read committed– no dirty reads; repeated reading of some
item may return different values
• repeatable read– adds stability of values to multiple reads of
items; may encounter phantom tuples
• serializable (= what it says)
![Page 12: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/12.jpg)
DBMS2001 Notes 9: Transaction Processing
12
Deadlocks
• Detection– Wait-for graph
• Prevention– Timeout– Wait-or-die– Wound-or-wait
![Page 13: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/13.jpg)
DBMS2001 Notes 9: Transaction Processing
13
Deadlock Detection
• Build a wait-for graph using lock table – Nodes: Active transactions; – Arcs: (T,U) iff T is waiting for a lock held by U
• Build incrementally or periodically• When a cycle found, rollback culprit(s)
T1
T3
T2
T6
T5
T4T7
![Page 14: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/14.jpg)
DBMS2001 Notes 9: Transaction Processing
14
Timeout
• If transaction uses more than L sec., cancel and roll it back!
• Simple scheme• Hard to select L• May lead to unnecessary rollbacks
(of non-deadlocked transactions)
![Page 15: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/15.jpg)
DBMS2001 Notes 9: Transaction Processing
15
Timestamp-Based Deadlock Prevention
• Each transaction Ti is given a timestamp ts(Ti) when it starts
• If ts(Ti) < ts(Tj), transaction Ti is older, and transaction Tj is younger
• Two schemes– Wait-or-die– Wound-or-wait– Both give privilege to older transactions
![Page 16: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/16.jpg)
DBMS2001 Notes 9: Transaction Processing
16
Wait-or-die
• When T requesting a lock held by U ...
• If T is older (i.e., ts(T) < ts(U)), T waits
• If T is younger (i.e., ts(T) > ts(U)), T "dies" (is rolled back)
![Page 17: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/17.jpg)
DBMS2001 Notes 9: Transaction Processing
17
T1
(ts =10)
T2
(ts =20)
T3
(ts =25)
wait
wait
Example: (Wait-or-die)
wait?
![Page 18: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/18.jpg)
DBMS2001 Notes 9: Transaction Processing
18
Wound-or-wait
• When T requesting a lock held by U ...• If T is older (i.e., ts(T) < ts(U)),
T “wounds” U– U is rolled back (releasing its locks), and
T gets the lock it requested
• If T is younger (i.e., ts(T) > ts(U)), T waits for U to release the lock
![Page 19: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/19.jpg)
DBMS2001 Notes 9: Transaction Processing
19
T1
(ts =10)
T2
(ts =20)
T3
(ts =25)
wait
wait
Example: (Wound-or-wait)
wait?
![Page 20: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/20.jpg)
DBMS2001 Notes 9: Transaction Processing
20
Why Do Wait-Die and Wound-Wait Work?
• Consider a deadlock, i.e., a cycleT1 T2 … Tn T1
in the wait-for graph• With wait-or-die only older transactions
wait, i.e., ts(T1) < ts(T2) < … < ts(T1), which is impossible
• With wound-or-wait only younger transactions wait, which similarly cannot lead to a wait-for cycle
![Page 21: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/21.jpg)
DBMS2001 Notes 9: Transaction Processing
21
Timestamp-based vs. wait-for-graph based deadlock-management
• Timestamp methods prevent starvation: Restarted transactions retain their timestamp each transaction becomes eventually oldest, and has a chance to finish
• Wait-die and wound-wait easier to implement than wait-for graphs (esp. for distributed databases)
• Wait-die and wound-wait may roll back transactions not involved in a deadlock
![Page 22: Principles of Database Management Systems 9: More on Transaction Processing](https://reader035.vdocuments.mx/reader035/viewer/2022062315/568151f9550346895dc031d4/html5/thumbnails/22.jpg)
DBMS2001 Notes 9: Transaction Processing
22
Summary
• Dirty reads and cascading rollback• Transaction isolation in practice• Deadlock
– detection – prevention