乐观锁的问题

[love19861018]

当数据库事务隔离模式是“读已提交时” 乐观锁（假设用时间戳实现）确实可以在一定程度上避免“丢失更新” 但是在高并发的场景下感觉还是可能会有点问题 例如A和B同时读取了一个表单进行修改，在多线程的情况下，会有这种情况，A通过了时间戳验证，但还没有真正提交事务，B此时如果进行时间戳校验也是可以通过验证的，也会存在B的更新把A的覆盖的现象，在一些文章中看到乐观锁假设事务会互补影响，这个假设成立吗？


欢迎拍砖！！！！

[MiceRice]

你说的是“READ COMMITTED”吧？

这个是指A读取数据时对记录添加共享锁，但读取结束立即释放。另一个B对这个记录的试图修改会一直等待直到A中的读取过程结束，而不需要整个A的结束。所以，在A的不同阶段对同一记录的读取结果可能是不同的。

也就意味着可能发生：不可重复读。也就是你说的“感觉还是可能会有点问题”


这个问题说白了很简单，就是如果两个线程同时执行类似于：
Select num --> i
i = i + 1;
Update num = i;
这种过程的时候，则可能发生数据覆盖。也就是你说的“也会存在B的更新把A的覆盖的现象”

避免的方法两种：
1、计算下推数据库，也就是直接把+1的运算让数据库来负责，三步操作合并为： Update num = num + 1
2、Select 的时候，升级锁，常用招数是： For Update


不知道我这么说你能理解不。。。

[love19861018]

[Quote=引用楼主 的回复:]
当数据库事务隔离模式是“读已提交时” 乐观锁（假设用时间戳实现）确实可以在一定程度上避免“丢失更新” 但是在高并发的场景下感觉还是可能会有点问题 例如A和B同时读取了一个表单进行修改，在多线程的情况下，会有这种情况，A通过了时间戳验证，但还没有真正提交事务，B此时如果进行时间戳校验也是可以通过验证的，也会存在B的更新把A的覆盖的现象，在一些文章中看到乐观锁假设事务会互补影响，这个假设成立吗？

……
[/Quote]

2、Select 的时候，升级锁，常用招数是： For Update
这种模式是用数据库的悲观锁 高并发的场景会影响系统性能

现在我的实现思路大概是：读取数据的时候不会加悲观锁 因为这样会影响性能，点击保存的时候先用乐观锁 也就是时间戳通过验证之后 再用悲观锁住本单据的主键 如果获取锁成功 将数据提交到数据库进行更新 然后释放悲观锁

[MiceRice]

Select For Update 是行锁，如果能确定的只操作一行，就不会互相影响。

不过首选还是运算操作下推数据库，这种最安全可靠。

建议把场景描述下，再具体讨论。

[love19861018]

[Quote=引用 3 楼 的回复:]
Select For Update 是行锁，如果能确定的只操作一行，就不会互相影响。

不过首选还是运算操作下推数据库，这种最安全可靠。

建议把场景描述下，再具体讨论。
[/Quote]

最后决定如下模式了：
1：实现一个主键锁

2：更新单据的时候采用如下逻辑：这样即兼顾了效率，又保证的业务数据的正确
if(申请主键锁)｛
if(校验时间戳){
更新数据
}
｝