Solutions for Chapter 10
(10.2)
--> T1 ---> T2 ---> T3 ---> loop back to T1
(10.6) (b) WL3(D) W3(D) WL1(F) W1(F) RL1(D) (conflict with WL3(D), T1 must wait for T3) WL2(F)(conflict with WL1(F), T2 must wait for T1; defer R2(G) because T2 is waiting) WL3(G) W3(G) C3 (T1 can now go with successful RL1(D)) R1(D) C1 (T2 can now go with successful WL2(F)) W2(F)RL2(G) R2(G) C2
(10.8) (b) (i) Here is the series of Log Entries written as a result of this history:
(S, 1) (W, 1, A, 1, 3) (S, 2) (S, 3) (C, 1) (W, 2,
D, 2, 5) (W, 3, B, 4, 6)
(CKPT, (LIST = T2, T3)) (W, 2, E, 8, 9) (C, 2) (W, 3, C, 7, 11)
(ii) The last write will not get out to the Log File, since no Commit forces it. Now we outline the actions taken by recovery:
Roll Back
|
1. (C, 2) |
Place T2 as a committed
transaction |
|
2. (W, 2, E, 8, 9) |
Committed write: wait for Roll Forward |
|
3. (CKPT, (LIST = T2, T3)) |
Note that T2 committed, T3 not committed in active list. |
|
4. (W, 3, B, 4, 6) |
Not committed, UNDO: B = 4 |
|
5. (W, 2, D, 2, 5) |
No Action |
|
6. (C,1) |
No Action |
|
7. (S, 3) |
Active list has ony committed transactions; end of Roll Back. |
Roll Forward (Jump to first Log Entry after Checkpoint)
|
8. (W, 2, E, 8, 9) |
Committed, REDO: E = 9 |
|
9. (C, 2) |
No action - last Log Entry, so done |
(iii) Picture
[10.12] (a) There is no problem unless the count is maintained separately in the database, say in ecount, just as the branch balance was held in a special record in the example. Then if T1 counts rows and during this count loop, T2 inserts a new row in the region already counted, and updates ecount, T1 will then finish up the loop, having obtained the old count, compare it against ecount, and find an inconsistency.
(b) The predicate: dept=’Math’ in the employees table, a read lock.
(c) The row for the new employee, for write. WL2(name=’Fred’, dept=’Math",...)
(d) The write lock request conflicts with the predicate lock, so T2 will wait until T1 commits.