乐观锁 并发 不足
0
最佳答案
0
“但如果直接简单这么做” 同 “通过校验阶段后，将更新的数据写入数据库” 是同一个意思吗？
收获园豆：19
差不多吧。对于加版本号的乐观锁，如果两个事务同时读取了数据库的某一行，版本号是一样的，再怎么校验也没用的，不知道哪个先修改，哪个后修改。。。
@S-Roc: “直到提交的时候才去锁定”，也就是说检查版本号和更新操作是原子的，当提交时，先锁定，然后检查版本号是否相同，如果相同，则更新（包括版本号），释放锁。
@Launcher: 先锁定，在查询？ 如果海量数据，又是多人并发？ 性能上有点问题吧？
@S-Roc: 性能上有问题又怎样？为了保证完整性，如果你不付出点代价，那我们还提“并发”干什么？关键的问题是，这种代价是否在可接受范围内，以及是否必须接受。通常更新记录的锁只对当前记录有效，而且我们假设业务场景中对同一记录的更新并不是一个非常严重的竞争条件，你能举例说明你的业务场景中涉及到对同一记录的修改并发数有多大吗？
其他回答(1)
0
应该在写回数据库的时候验证原始值再更改吧，如果之前读取的原始值与更改前的值不一致就表示被别人改了，这时候就阻止提交
收获园豆：1
