Best practice for avoiding Lost update

IsDonIsGood

如题，放狗之前想问问坛子里的大虾们一般都是怎么解决lost update的问题的？
谢啦！

dalaohu

what？

乱码

原帖由 IsDonIsGood 于 2010-12-6 13:25 发表
如题，放狗之前想问问坛子里的大虾们一般都是怎么解决lost update的问题的？
谢啦！

用一个timestamp mark最近一次的改动，update之前要validate这两个是否相等，如果不等，出提示，重新load.

IsDonIsGood

原帖由 乱码 于 2010-12-6 14:30 发表


用一个timestamp mark最近一次的改动，update之前要validate这两个是否相等，如果不等，出提示，重新load.

谢啦，这个方法够简单。

澳贼

乱码

原帖由 澳贼 于 2010-12-6 15:37 发表
乱码真的是什么都知道啊

你要是我老板就好了

dalaohu

I have no idea what is lost update?

乱码

Lost Updates

Lost updates occur when two or more transactions select the same row and then update the row based on the value originally selected. Each transaction is unaware of other transactions. The last update overwrites updates made by the other transactions, which results in lost data.

For example, two editors make an electronic copy of the same document. Each editor changes the copy independently and then saves the changed copy, thereby overwriting the original document. The editor who saves the changed copy last overwrites changes made by the first editor. This problem could be avoided if the second editor could not make changes until the first editor had finished.

http://msdn.microsoft.com/en-us/library/aa213029(SQL.80).aspx

dalaohu

乱码回答了， 我还是一点没明白你们在讲什么。。。

真的out 了！

dalaohu

原帖由 乱码 于 2010-12-6 15:49 发表
Lost Updates

Lost updates occur when two or more transactions select the same row and then update the row based on the value originally selected. Each transaction is unaware of other transactions. Th ...

靠， sql transaction...

怎么问的那么神秘。。。

dalaohu

Concurrency Problems 怎么能用timestamp？ 难道locks 都不用了吗？
我还是继续out。

乱码

原帖由 dalaohu 于 2010-12-6 15:56 发表
Concurrency Problems 怎么能用timestamp？ 难道locks 都不用了吗？
我还是继续out。

不是局限在database level的，而是不同的session(用户）对同一条record的修改，如果A commit在先，其他的session在A read & commit之间读出来的data就有误，很有可能不是他们当时看到的，所以要重新read A 修改过的数据，然后再modify.

这是我的猜测，看来像是lz的case.

kr2000

如果多人可以修改的同一个东西，是不是应该加一个checkout的值，如果checkout了其他人就不能改了

典

不知道具体是什么情况，个人觉得这个不是技术问题了，应该问你的用户或者B/A要怎么处理，
大部分还是在流程控制/状态/版本上想办法，尽量避免这种情况的发生
必要的时候加入中间步骤，

coolioo

参考 oracle "select for update"

IsDonIsGood

原帖由 典 于 2010-12-6 21:47 发表
不知道具体是什么情况，个人觉得这个不是技术问题了，应该问你的用户或者B/A要怎么处理，
大部分还是在流程控制/状态/版本上想办法，尽量避免这种情况的发生
必要的时候加入中间步骤， ...

确实牵涉不到DB上的transaction控制，case非常简单，用户A访问page X,然后对一个business record做一些改动，在用户A commit change之前，用户B 同样访问 page X，然后在用户A commit change 之後，B commit change, 這樣A的change就看不到了，就是所謂的 lost update.
想要解決的就是reject用戶B 所commit 的change.
應該是個比較普遍的case吧，是不是有別的說法

典

这样 的话你 已经 解决 了问题 的  90%，因为 思路已经 有 了
看起 来 似乎   用 版本 控制比较 方便 ，每次 更改 版本号自动 加 1，更改 之前 CHECK数据库 里 的 版本 号，
比如说  A和 B都 取得 了版本 号 为 3的 一条 记录 ，A改 完 后 变 4了 ，B进来 commit  的 时候 会发现数据 库里的 版本号已经 变得 比 自己的 版本号 大 ，无法 更改 。仅供 参考 ，  Timestamp  is similar

[ 本帖最后由 典 于 2010-12-6 21:27 编辑 ]

IsDonIsGood

版本号确实更容易控制，不过直接用现成的updateddate会更方便一些，不需要再引入一个field了。