MySQL 更新不成功，事务问题搞清楚了吗？

一个忙（mo）碌（yu）的下午，小航同学，突然大骂一声，“TM ，见鬼了，version没变，更新就是不成功”。

我看他，满头大汗，双手握拳，面目狰狞，似乎又要发作，赶紧说：“不成功没关系啊，重试就好，乐观锁一般是要重试的”

他略带鄙视的说道：代码有重试了逻辑，我还加日志了，结果发现version没变，就是更新不成功。

作为对技术小有追求的人，他怎么一说，立刻引起了我的好奇，随后诚恳的说道，我能看看代码吗？

小航，一句不发，双手却笔画了个请的姿势。

我仔细端详，代码大致逻辑如下：

@Transactional(timeout = 36000, rollbackFor = Throwable.class)
public void updateGoodNum(String id,Integer num)
      throws Exception {
    //1. select num as  dbnum,version as dbversion  from t where id=#{id}
    //2. update t set num=dbnum-num,version =dbversion +1  
    // where id=#{id} and version =dbversion  ;
    // 如果更新失败，重试1,2部总共3回
}

 

我轻叹了口气，在mysql连接工具执行了，如下语句，将截图发给小航后，

 

摆出个大师的模样说道：咱们测试环境隔离级别是RR（REPEATABLE-READ），在一个事务中重试是不行的！

小航难为情的说的：大哥，什么是隔离级别啊？ 为什么不行啊？ 怎么改呢？

 

隔离级别

隔离级别	说明
READ UNCOMMITTED	未提交读，会造成脏读，违反持久性D
READ COMMITTED	读已提交数据， 会造成幻读 违反一致性C
REPEATABLE READ（RR）	可重复读，默认隔离级别， 事务中的select 语句会读取事务开始前的快照，当然也能读到本事务的更新内容
SERIALIZABLE	不会使用mysql的mvcc机制，而是在每一个select请求下获得读锁，在每一个update操作下尝试获得写锁

update操作是读取当前值。

那在RR隔离级别下，为什么在一个事务中重试是不行的呢？

表格模拟，为什么不行？

开始事务前	表t对应id=1的,version=1
	事务A begin	事务B begin
1	select version from t where id=1; -- 得到version=1	update t set version=2 where id=1; commit;
2	update t set XX where id=1 and version=1； // 更新失败，update读取当前，version=2
3	select version from t where id=1; // 得到version=1
4	commit

注意：事务中的select 是读快照，update是读当前。

简单说，就去其他事务，已经将version修改了2，事务A看到的还是事务开始前的值

也就是version为1.

解决方式

RR隔离级别下，将重试移到事务外. 即每次重试重新开一个事务

概要逻辑如下

/// 如果更新失败，重试updateGoodNum总共3回
public AFacadeImpl{
    @Autowired
    AService aservice;
    public void updateGoodsNum(){
        int i = 0; 
        while(!aservice.updateGoodNum(id,num) && i++ < 3);
    }
}

public AServiceimpl implement AService{
　　@Transactional(timeout = 36000, rollbackFor = Throwable.class)
　　public boolean updateGoodNum(String id,Integer num)
      throws Exception {
    //1. select num as  dbnum,version as dbversion  from t where id=#{id}
    //2. update t set num=dbnum-num,version =dbversion +1  
    // where id=#{id} and version =dbversion  ;
    /
　　}
}

转自https://my.oschina.net/floor/blog/4784609