Lost Update Vs Uncommitted Data

Lost Update	Uncommitted Data
This problem is also known as “Multiple Update problem”	This problem is also known as “Dirty Read”
In the multiple update problem, the data written by one transaction is being overwritten by another transaction.	In Dirty read, data written by one transaction is read by another transaction before that transaction commits.
Two transaction accessing the same database item have their operations interleaved in a way that makes the database item incorrect.	This problem occurs when one transaction is allowed to see the intermediate result of the another transaction before it is committed.
Example : Connection A Connection B    ………    ……… SELECT Row1    ………    ………    ………    ……… SELECT Row1    ………    ……… UPDATE Row1    ………    ………    ………    ……… UPDATE Row1	Example : Connection A Connection B    ………    ………    ………  UPDATE Row1    ………    ……… SELECT Row1    ………    ………    ………    ………  ROLLBACK
Situation : Connection A and B both read a record and then update it, the effect of the first update will be overwritten by the second update.	Situation : Connection A reads an object that has been modified by Connection B but Connection B has not committed yet. Here, Connection B rollback transaction and uncommitted data is already read by Connection A. This is known as “Uncommitted Dependency”
Problem : Connection A and B both reading old value. Here Connection A updates row after some time Connection B updates that row. So, changes made by Connection A would be lost.	Problem : Connection A was permitted to read the intermediate result of Connection B before the Connection B was terminated.
Solution : Prohibit a shared lock Use batch processing Implementing locking scheme Two phase locking also solve this problem	Solution : Prevent Connection A from reading the account balance until the Connection B is terminated. i.e. either committed or rollback.