乐观锁的问题

Question

你说的是“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
不知道我这么说你能理解不

Answer 1

2、Select 的时候，升级锁，常用招数是： For Update
这种模式是用数据库的悲观锁 高并发的场景会影响系统性能现在我的实现思路大概是：读取数据的时候不会加悲观锁 因为这样会影响性能，点击保存的时候先用乐观锁 也就是时间戳通过验证之后 再用悲观锁住本单据的主键 如果获取锁成功 将数据提交到数据库进行更新 然后释放悲观锁

Answer 2

Select For Update 是行锁，如果能确定的只操作一行，就不会互相影响。不过首选还是运算操作下推数据库，这种最安全可靠。建议把场景描述下，再具体讨论。

Answer 3

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