This famous problem is known as a "lost update"

原创 2004年07月07日 20:50:00

Each of the instances of the component performs the following steps:
1. Read an integer X from a database.
2. Add 10 to X.
3. Write the new value of X to the database.

If each these three steps exceutes together in an atomic operation, everthing
is fine. Neither instance can interfere with the other instance's operations.
Remember, though, that the thread-scheduling algorithm being used in the
backgroud does not guarentee this. If two instances are executing these three
operations, the operations could be interleaves. The follwing order of operations
is possible:

1. Instance A reads integer X from database. The database now contains X = 0.
2. Instance B reads integer X from database. The database now contains X = 0.
3. Instance A adds 10 to its copy of X and persists it to the database. The
   database now contains X = 10.
4. Instance B adds 10 to its copy of X and persists it to the database. The
   database now contains X = 10;
  
What happened here? Due to the interleaving of database operations, instance
B is working with a stale copy of X: The copy before instance A performed a
write. Thus, instance A's operations have been lost! This famous problem is
known as a "lost update"
. It is very serious situation-instance B has been
working with stale data and has overwritten instance A's write. How can
transactions avoid this scenario?

The solution to this problem is to use "locking" on the database to prevent the
two components from reading data. By locking the data your transaction is using,
you guarantee that your transaction and only your transaction has access to
that data until you release that lock. This prevents interleaving of sensitive
data operations.

In our scenario, if our component acquired an exclusive lock before the trans-
action began and released that lock after the transaction, then no interleaving
would be possible.

1. Request a lock on X.
2. Read an integer X from a database.
3. Add 10 to X.
4. Write then new value of X to the database.
5. Release the lock on X.

If another component ran concurrently with ours, that component would have to
wait until we relinguished our lock, which would give that component our
fresh copy of X.

Lost Update | Dirty Read | Unrepeatable Read | Phantom Read

Lost Update | Dirty Read | Unrepeatable Read | Phantom Read
  • wwq518
  • wwq518
  • 2016-04-27 16:31:30
  • 571

Sicily 1161. Songs

1161. Songs Constraints Time Limit: 1 secs, Memory Limit: 32 MB Description John D...
  • u012925008
  • u012925008
  • 2015-03-17 15:59:59
  • 392

贪心算法:田忌赛马-HDU1052 & POJ2287 & ZOJ2397

/* http://acm.hdu.edu.cn/showproblem.php?pid=1052 http://poj.org/problem?id=2287 http://acm.zju.edu....
  • leolinsheng
  • leolinsheng
  • 2014-02-13 22:37:42
  • 2379

POJ 2675 Songs (贪心)

Songs Time Limit:1000MS    Memory Limit:65536KB    64bit IO Format:%I64d & %I64u SubmitStatus ...
  • u013446688
  • u013446688
  • 2014-08-04 10:06:47
  • 774

HOJ P2143 Song(贪心)

HOJ P2143 Song ------------------------------------ Problem Description Time limit : 1 s   Memory l...
  • weixin_40883049
  • weixin_40883049
  • 2017-12-01 20:37:51
  • 49

田忌赛马后传 &nyoj 田忌赛马 364 (贪心)

田忌赛马后传 Time Limit : 3000/1000ms (Java/Other)   Memory Limit : 65535/32768K (Java/Other) Total Sub...
  • yanghui07216
  • yanghui07216
  • 2016-03-26 20:59:45
  • 460

杭电ACM1002

(1)题目大意: Here is a famous story in Chinese history. "That was about 2300 years ago. General Ti...
  • yjz_sdau
  • yjz_sdau
  • 2016-04-01 19:18:41
  • 354

HDU4247:A Famous ICPC Team

Problem Description Mr. B, Mr. G, Mr. M and their coach Professor S are planning their way to Warsa...
  • libin56842
  • libin56842
  • 2013-12-01 20:40:24
  • 1676

acm之贪心算法题目4

Problem DescriptionHere is a famous story in Chinese history.“That was about 2300 years ago. General...
  • shelly1072
  • shelly1072
  • 2016-06-26 10:09:22
  • 302

1000 Tables Moving

1000 Problem A The famous ACM (Advanced Computer Maker) Company has rented a floor of a building who...
  • diyutianxie
  • diyutianxie
  • 2016-03-20 18:58:10
  • 498
收藏助手
不良信息举报
您举报文章:This famous problem is known as a "lost update"
举报原因:
原因补充:

(最多只允许输入30个字)