首页 新闻 搜索 专区 学院

乐观锁 并发 不足

0
悬赏园豆:20 [已解决问题] 解决于 2014-09-24 21:51

优点与不足[编辑]

乐观并发控制相信事物之间的数据竞争(data race)的概率是比较小的,因此尽可能直接做下去,直到提交的时候才去锁定,所以不会产生任何锁和死锁。但如果直接简单这么做,还是有可能会遇到不可预期的结果,例如两个事务都读取了数据库的某一行,经过修改以后写回数据库,这时就遇到了问题[2]

 

 

请问各位大神对于这种情况:例如两个事务都读取了数据库的某一行,经过修改以后写回数据库,这时就遇到了问题[2]

有解决的方案的吗  ?还是乐观锁  也解决不了版本并发的问题? 还有其他的方案解决版本并发?

Roc-Lee的主页 Roc-Lee | 初学一级 | 园豆:12
提问于:2014-04-16 09:47
< >
分享
最佳答案
0

“但如果直接简单这么做” 同 “通过校验阶段后,将更新的数据写入数据库” 是同一个意思吗?

收获园豆:19
Launcher | 高人七级 |园豆:45045 | 2014-04-16 09:59

差不多吧。对于加版本号的乐观锁,如果两个事务同时读取了数据库的某一行,版本号是一样的,再怎么校验也没用的,不知道哪个先修改,哪个后修改。。。

Roc-Lee | 园豆:12 (初学一级) | 2014-04-16 10:10

@S-Roc: “直到提交的时候才去锁定”,也就是说检查版本号和更新操作是原子的,当提交时,先锁定,然后检查版本号是否相同,如果相同,则更新(包括版本号),释放锁。

Launcher | 园豆:45045 (高人七级) | 2014-04-16 10:20

@Launcher: 先锁定,在查询?   如果海量数据,又是多人并发?  性能上有点问题吧?

Roc-Lee | 园豆:12 (初学一级) | 2014-04-16 10:53

@S-Roc: 性能上有问题又怎样?为了保证完整性,如果你不付出点代价,那我们还提“并发”干什么?关键的问题是,这种代价是否在可接受范围内,以及是否必须接受。通常更新记录的锁只对当前记录有效,而且我们假设业务场景中对同一记录的更新并不是一个非常严重的竞争条件,你能举例说明你的业务场景中涉及到对同一记录的修改并发数有多大吗?

Launcher | 园豆:45045 (高人七级) | 2014-04-16 10:58
其他回答(1)
0

应该在写回数据库的时候验证原始值再更改吧,如果之前读取的原始值与更改前的值不一致就表示被别人改了,这时候就阻止提交

收获园豆:1
诶碧司 | 园豆:1912 (小虾三级) | 2014-04-16 17:19
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册