Answer : B,D
Strict recoverable schedules are free from $WW,WR$ conflicts But they are not free from $RW$ conflict and Lost update problem.
| T1 |
T2 |
| R(X) |
|
| |
W(X) |
| commit |
|
| |
commit |
Clearly, there is $RW$ conflict But this is Strict recoverable schedule.
What is Lost Update Problem ??
As stated in Korth,
The lost update anomaly is said to occur if a transaction $Tj$ reads a data item, then another transaction $Tk$ writes the data item (possibly based on a previous read), after which $Tj$ writes the data item. The update performed by $Tk$ has been lost, since the update done by $Tj$ ignored the value written by $Tk$.
Following example is from Navathe.
.
The Lost Update Problem occurs when two transactions that access the same database items have their operations interleaved in a way that makes the value of some database items incorrect. Suppose that transactions T1 and T2 are submitted at approximately the same time, and suppose that their operations are interleaved as shown in Figure 21.3(a); then the final value of item X is incorrect because T2 reads the value of X before T1 changes it in the database, and hence the updated value resulting from T1 is lost. For example, if X = 80 at the start (originally there were 80 reservations on the flight), N = 5 (T1 transfers 5 seat reservations from the flight corresponding to X to the flight corresponding to Y), and M = 4 (T2 reserves 4 seats on X), the final result should be X = 79. However, in the interleaving of operations shown in Figure 21.3(a), it is X = 84 because the update in T1 that removed the five seats from X was lost.
Typically, one transaction updates an item, while another that began very shortly afterward did not see this update before updating the same value itself. The result of the first transaction is then "lost", as it is simply overwritten by the second transaction.
Lost Update problem looks like the following :
| T1 |
T2 |
| |
Reads(X) |
| Writes(X) |
|
| |
Writes(X) |
In Serializable schedules (Conflict Serializable), We DO NOT have lost update problem because when there is lost update problem, there will be cycle in the precedence graph, So Not Conflict serializable.
Still In View Serializable schedules, there could be Lost Update Problem.
For eg,
| T1 |
T2 |
T3 |
| |
R(X) |
|
| W(X) |
|
|
| |
W(X) |
|
| |
|
W(X) |
This schedule has lost update problem But it is view serializable (View equivalent to T2,T1,T3 serial schedule).
Lost update problem may exist in Strict recoverable schedules as well. For eg,
| T1 |
T2 |
| |
Reads(X) |
|
Read(X)
Writes(X)
|
|
| Commit |
|
| |
Writes(X) |
This schedule is Strict Recoverable But it has lost update problem.
Extra Notes :
The lost update problem occurs whenever two transactions, while attempting to modify a data item, both read the item’s old value before either of them writes the item’s new value.
