4,141 views
3 votes
3 votes
If schedule is Serializable then free from WW, RW,WR .But Lost update may be possible .

please explain how in serializable schedule lost update problem still exist.

2 Answers

11 votes
11 votes

If schedule is Serializable then free from WW, RW,WR .

No. Who said Serializable schedules are free from these conflicts ??  These all three types of conflicts may be present in a Serializable schedule.

Strict recoverable schedules are free from $WW,WR$ conflicts But even they are not free from $RW$ conflict. 

But Lost update may be possible .

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)

 


 how in serializable schedule lost update problem still exist.

NO. 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. 

The following is a para from Navathe :

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).


Recoverability and Serializability are two different things. 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. 

 

edited by
1 votes
1 votes
great explaination!!!

Related questions

1 votes
1 votes
1 answer
1
sumit goyal 1 asked Aug 20, 2017
745 views
IN these questions , in T1 it will read value of A from hard disk or local buffer and W(A) when execute it will make change in local buffer or hard disk , are w(A) and ...
0 votes
0 votes
1 answer
3
Deepalitrapti asked Aug 17, 2018
1,195 views