0 / 5
Lost Update
When two transactions read the same data and each writes back its own change, the later write overwrites the earlier one and one of the updates is lost.
Follow the order in which the operations of the two sales interleave.
1 / 5
T1 reads the stock
T1 reads stock X. Its value is now 10.
2 / 5
T2 also reads the stock
T1 has not written yet, so T2 also reads 10.
3 / 5
T1 writes 9
T1 subtracts 1 from the 10 it read and writes 9.
4 / 5
T2 overwrites T1’s value
T2 also subtracts 1 from the 10 it read and writes 9. It computed without knowing about the 9 that T1 wrote, so it overwrites T1’s update.
5 / 5
Result: lost update
There were two sales, but the stock dropped by only one.
Cause:T2 computed with the 10 it read before T1 wrote 9.
1 / 4
T1 writes 9
T1 writes 9 to X. It is still checking the payment, so it has not committed yet.
2 / 4
T2 reads an intermediate value
T2 reads the 9 that is not final and shows “9 in stock” on screen.
3 / 4
T1 cancels
The payment fails, so T1 rolls back. The stock goes back to 10.
4 / 4
Result: dirty read
The 9 that T2 showed was never made final.
Unlike cascading rollback:The problem here is that an uncommitted value has already gone out to the screen. Cascading rollback is the recovery problem that every transaction which read that value must roll back too.
1 / 6
T1 reads A
T1 reads the balance of A, which is 100.
2 / 6
T2 subtracts 50 from A
T2 subtracts 50 from A. It has not added anything to B yet.
3 / 6
T2 adds 50 to B
T2 adds 50 to B.
4 / 6
T2 makes the transfer final
T2 commits to make the transfer final. The real total is still 200.
5 / 6
T1 reads B
By the time T1 reads B, the transfer is already done, so B is 150.
6 / 6
Result: inconsistent analysis
The A that T1 read is from before the transfer, and the B is from after it. So T1 got a total of 250 that never existed.
Note:In this example, the values stored in the DB are correct. Only the total that T1 computed does not add up.
1 / 7
T1 writes 9
T1 writes 9 to X. It has not committed yet.
2 / 7
T2 reads an intermediate value
T2 reads the 9 that is not final.
3 / 7
T2 writes 8 based on 9
T2 subtracts 1 from 9 and writes 8. It computed with a value that T1 wrote before Commit.
4 / 7
T1 starts to cancel
The payment fails, so T1 must roll back. But T2 has already written 8 over the 9 that T1 wrote. T2 must be undone first before T1’s 9 can be undone.
5 / 7
T2 is canceled too
T2 computed with a 9 that is now invalid, so it rolls back. The DB sets the 8 that T2 wrote back to 9.
6 / 7
T1 finishes canceling
The DB sets the 9 that T1 wrote back to 10. Only now is it back to the original value, 10.
7 / 7
Result: cascading rollback
When T1 rolled back, T2, which had read a value T1 wrote, had to roll back too. If a T3 had read T2’s value, T3 would have to roll back next.
Unlike dirty read:In a dirty read, the problem is the result of reading an uncommitted value. In a cascading rollback, the problem is that every transaction that read it must roll back in turn. In this example, even the 8 that T2 wrote had to be undone.Note:If T2 had already committed, T2 could not even roll back. An execution order like this is called a nonrecoverable schedule.