事务的那些坑

àì夳堔傛蜴生んèń 2022-06-18 02:22 391阅读 0赞 
  1.       总结一下事务在使用过程中的一些坑。
  3.       在介绍之前，先普及一些基础知识

一、基础知识

事务隔离等级

  1.              一般事务的隔离等级有Read uncommitted，Read committed，Repeatable read，Serializable。其中隔离程度越来越严格，到了Serializable已经不支持并发事务了。

Read uncommitted

  1.             会造成脏读，可重复读，幻读。什么是脏读，看一下关键词uncommitted，英文很直白。网上很多抄来抄去的文章很多把脏读和不可重复读混淆。特别是乐观锁的文章。脏读也就是说读取到别人未提交的事务中的改动。举个例子：
  3.             原数据  id=1 value=6
  5.             事务A                                        事务B  
  8.             修改id=1的数据value=8  
  11.                                                               读取id=1的数据value=8  
  14.             commit

Read committed

  1.                 会造成可重复读，幻读。read committed字面上已经表明了只能读取到事务提交后的数据，所以避免了脏读。什么是可重复读，可重复读是指在事务中前后读取两次同一数据，由于在此期间，存在其他事务修改该数据并提交，造成前后读取不一致。举个例子
  3.              原数据  id=1 value=6
  5.              事务A                                        事务B
  7.              读取id=1的数据value=6
  9.                                                                修改id=1的数据value=8
  11.                                                                commit
  13.                读取id=1的数据value=8

Repeatable read

  1.                   会造成幻读。Repeatable read字面上也表明了可以在事务中重复读取。比如mysql中的实现方式是事务开始后的select将会把结果存在临时数据中。事务中再次读取时直接从临时数据中取值，因此可以重复读取。但是这只保证了update操作，对于insert操作，则会产生幻读。举个例子：
  3.                  原数据  id=1 value=6
  5.                 事务A                                        事务B
  7.                读取id=1的数据 value=6  
  10.                                                                   新增一行数据id=1 value=8  
  13.                                                                   commit
  15.                读取id=1的数据 value=6
  17.                                         value=8
  19.                这样得到了两条数据，则是幻读。

Serializable

  1.                不允许并发事务，不会产生任何并发问题。

乐观锁

  1.              乐观锁和之前的事务隔离等级一样，也是为了解决一些并发问题。乐观锁解决的问题如下：

不可重复读

  1.               从之前的事务隔离等级已经知道Repeatable read则可以解决不可重复读，乐观锁和它之间还是有区别的。
  3.              如果在一个事务中防止读取另一个已提交事务造成的重复读，在这一点上和Repeatable read的区别是，如果是Repeatable read，还是可以获得事务开始时的值，而乐观锁你只知道值变了，无法获得原始值。

更新丢失

  1.              乐观锁的作用范围超过了事务。考虑如下场景，用户A打开了修改界面，修改界面读取当前数据显示。然后用户A去做其他事情了。这时候用户B修改了同样的数据。用户A回来继续修改，提交事务则覆盖了用户B的修改。

只读事务

  1.             在数据库层面，只读事务的作用也是解决不可重复读的问题，并且不允许该事务中存在除了查询以外的操作。

事务传播等级

  1.             spring提出的概念，这里只介绍容易混淆的等级
  3.             **PROPAGATION\_REQUIRED**：如果当前不存在事务，则新建事务，否则使用当前事务。如果遇到内部事务，把外部事务作为内部事务。
  5.            **PROPAGATION\_REQUIRES\_NEW**：不论何时，总是新建事务。如果遇到内部事务，则挂起外部事务，内部事务处理完，继续外部事务。
  7.            **PROPAGATION\_NESTED**：嵌套事务，规则是这样的，外部事务在进入内部事务的时候，建立一个save point，并且挂起，如果内部事务回滚，则回滚到save point，然后继续执行外部事务。如果外部事务回滚，则同时回滚内部事务。
  9.           通过举例子的方式来说明 这几个事务传播等级的区别，主要是作为内部事务的情形。
  11.           由于只讨论内部事务，外部事务假设为任何一种等级的事务。例子均用伪码表示。

内部事务为PROPAGATION_REQUIRED

  1.           例子1：
  3. @Transactional
  5. public void method(){
  7.       doSomeThingInDB();
  8.       methodRequired();
  9.       throw newException();
  11.  }
  13.          方法methodRequired使用propagation\_required事务，并且成功提交。外部事务回滚，methodRequired的操作也回滚。
  15.          原因：内部事务和外部事务是同一个。
  17.          例子2：
  19. @Transactional
  20. public void method(){
  22.       doSomeThingInDB();
  23.       methodRequiredRollBack();
  25. }
  27.         方法methodRequiredRollBack使用propagation\_required事务，并且回滚。外部事务同样回滚。
  29.         原因：内部事务和外部事务是同一个。

内部事务为PROPAGATION_REQUIRED_NEW

  1.        例子1：
  3. @Transactional
  4. public void method(){
  6.       doSomeThingInDB();
  7.       methodRequiredNew();
  8.       throw new Exception();
  10. }
  16.         方法methodRequiredNew使用propagation\_required\_new事务，外部事务回滚，不影响内部事务。
  18.         原因：内部事务和外部事务是不同的事务。  
  21.        例子2：
  23. @Transactional
  24. public void method(){
  26.       doSomeThingInDB();
  27.       methodRequiredNewRollBack();
  29. }
  31.        方法methodRequiredNewRollBack使用propagation\_required\_new事务，并且回滚，不影响外部事务。  
  32.        原因：内部事务和外部事务是不同的事务。

内部事务为PROPAGATION_NESTED

  1.        例子1
  3. @Transactional
  4. public void method(){
  6.       doSomeThingInDB();
  7.       methodNested();
  8.       throw new Exception();
  10. }
  12.       方法methodNested使用propagation\_nested事务，外部事务回滚，内部事务也回滚。
  14.       原因：嵌套事务外部事务回滚，内部事务也回滚。
  16.       例子2
  18. @Transactional
  19. public void method(){
  21.       doSomeThingInDB();
  22.       try{
  23.            methodNestedRollBack();
  24.       }catch(Exception e){
  25.            doSomeThingInDB();
  26.      }
  28. }
  34.      方法methodNestedRollBack使用propagation\_nested事务，并且回滚，此时外部事务可以继续catch中的操作，如果没有抛出，可正常提交外部事务。
  36. @Transactional
  37. public void method(){
  39.       doSomeThingInDB();
  40.       try{
  41.            methodNestedRollBack();
  42.       }catch(Exception e){
  43.            doSomeThingInDB();
  44.            throw new Exception();
  45.      }
  47. }
  49.      方法methodNestedRollBack使用propagation\_nested事务，并且回滚，外部事务在catch中抛错回滚。此时，内部事务和外部事务均回滚。
  51.      原因：嵌套事务中，如果内部事务回滚，不影响外部事务。但是外部事务回滚，内部事务也会回滚。

二、事务中的坑

乐观锁与可重复读

  1.          乐观锁其实在更大范围确保了可重复读的问题，如果你的事务隔离等级为可重复读，mysql的默认等级，你又使用了乐观锁的话，你一定要小心谨慎，不然很可能出错。举个很经典的例子，死循环。
  5. public void update(String id){
  6.    DataVo vo=mapper.getById(id);
  7.    while(mapper.update(vo)==0){
  8.         vo=mapper.getById(id)
  9.    }
  10. }
  12.         其中vo中包含版本号或时间戳。死循环的过程如下：
  14.         事务A                                                                             事务B  
  17.         执行update方法
  19.         mapper.getById(1)获得版本号为1
  21.                                                                                                 修改id=1的数据，版本号变为2
  23.                                                                                                 commit
  25.        由于版本号为2，没有数据被更新，返回0
  27.        执行循环中的mapper.getById(1)获得版本号为1
  29.        由于版本号为2，没有数据被更新，返回0
  31.        执行循环中的mapper.getById(1)获得版本号为1
  33.        无限循环这两个步骤

readonly是否为只读事务

  1.         从数据库的层面我们知道只读事务可以解决重复读的问题，并且防止该事务中的任何非查询操作。但是我们在数据库驱动中设置的readonly属性真的就是数据库层面的只读事务吗。
  3.         这个问题没有确切的答案，需要看具体的驱动实现。比如：在老版本的oralce驱动中确实是设置了只读事务，而在新驱动中则只设置连接为只读。而且甚至在事务中存在非查询操作也不会报错。
  5.         下面来看看mysql中的情况，驱动为mysql-connector-java-5.1.38.jar。
  7.         看一下源码，exec方法
  9. if(!checkReadOnlySafeStatement()) {
  10. throw SQLError.createSQLException(Messages.getString("PreparedStatement.20") //$NON-NLS-1$
  11.                                 + Messages.getString("PreparedStatement.21"), //$NON-NLS-1$
  12. SQLError.SQL_STATE_ILLEGAL_ARGUMENT, getExceptionInterceptor());
  13.             }
  15.         其中checkReadOnlySafeStatement的源码
  17. protected boolean checkReadOnlySafeStatement() throws SQLException {
  18.         synchronized (checkClosed()) {
  19.             return ((!this.connection.isReadOnly()) || (this.firstCharOfStmt == 'S'));
  20.         }
  21.     }
  23.         我们看到这里的readonly仅仅是connection的readonly，并不是事务的readonly。因此，基于驱动的spring中的@Transactional(readOnly=true)自然也不是只读事务。不过它还是会对非查询操作回滚，比oralce的某些驱动好些。
  25.         我们可以做个试验
  27.         1、事务隔离级别设为READ\_COMMITTED，readOnly=true，中途修改数据
  29.        在获取了用户以后线程sleep3秒，在这个时候修改数据库，把该用户的loginname进行修改  
  32. @Override
  33.     @Transactional(isolation=Isolation.READ_COMMITTED,readOnly=true)
  34.     public DataGrid<UserVo> auditor(UserVo vo) throws Exception {
  35.         UserVo v=userMapper.findUserById("3af99f64-df20-4ffe-95df-a1d7ac5e84e8");
  36.         System.out.println(v.getLoginname());
  37.         TimeUnit.SECONDS.sleep(3);
  38.         v=userMapper.findUserById("3af99f64-df20-4ffe-95df-a1d7ac5e84e8");
  39.         System.out.println(v.getLoginname());
  40.         DataGrid<UserVo> vos=datagridMap(vo, userMapper, DBTYPE_MYSQL, "findCurrentAuditor","foundCount");
  41.         return vos;
  42.     }
  44.          结果如下：

Center

  1.          结论，事务隔离等级比Repeatable read低的情况下，会造成不可重复读，readOnly并不是只读事务。
  3.          2、readOnly=true，其中有删除操作  
  6. @Override
  7.     @Transactional(readOnly=true)
  8.     public DataGrid<UserVo> auditor(UserVo vo) throws Exception {
  9.         Map<String,Object> params=new HashMap<>();
  10.         params.put("id", "1");
  11.         userMapper.deleteRoles(params);
  12.         DataGrid<UserVo> vos=datagridMap(vo, userMapper, DBTYPE_MYSQL, "findCurrentAuditor","foundCount");
  13.         return vos;
  14.     }
  16.          其中存在删除操作，会抛出异常  
  19.          结论，虽然不是只读事务，但是任然不允许处查询操作之外的操作  
  22.          3、readOnly=true，或不设置readOnly=true，中途修改数据  
  25. @Transactional(readOnly=true)
  26.     public DataGrid<UserVo> auditor(UserVo vo) throws Exception {
  27.         UserVo v=userMapper.findUserById("3af99f64-df20-4ffe-95df-a1d7ac5e84e8");
  28.         System.out.println(v.getLoginname());
  29.         TimeUnit.SECONDS.sleep(3);
  30.         v=userMapper.findUserById("3af99f64-df20-4ffe-95df-a1d7ac5e84e8");
  31.         System.out.println(v.getLoginname());
  32.         DataGrid<UserVo> vos=datagridMap(vo, userMapper, DBTYPE_MYSQL, "findCurrentAuditor","foundCount");
  33.                 return vos;
  34. }
  36. @Transactional
  37.     public DataGrid<UserVo> auditor(UserVo vo) throws Exception {
  38.         UserVo v=userMapper.findUserById("3af99f64-df20-4ffe-95df-a1d7ac5e84e8");
  39.         System.out.println(v.getLoginname());
  40.         TimeUnit.SECONDS.sleep(3);
  41.         v=userMapper.findUserById("3af99f64-df20-4ffe-95df-a1d7ac5e84e8");
  42.         System.out.println(v.getLoginname());
  43.         DataGrid<UserVo> vos=datagridMap(vo, userMapper, DBTYPE_MYSQL, "findCurrentAuditor","foundCount");
  44.                 return vos;
  45. }         
  47.        在获取了用户以后线程sleep3秒，在这个时候修改数据库，把该用户的loginname进行修改
  49.         两者结果如下：

Center 1 

  1.          结论：默认事务隔离等级Repeatable read确保了可重复读

同类中的事务传播等级

  1.         同一个类中的方法之间调用，事务传播等级会失效。原因是事务是通过动态代理实现的，同类中的方法调用不是代理类。
  3.         解决办法是引入aspectjweaver.jar，然后开启暴露aop代理给ThreadLocal,比如xml的配置如下：
  5. <aop:aspectj-autoproxy proxy-target-class="true" expose-proxy="true"/>
  7.         代码中如下调用：
  9. ((Service) AopContext).method();

事务与缓存可重复读

  1.           隔离等级为Repeatable read的事务可以重复读取同一数据，然而同时使用缓存的时候要格外小心，因为缓存很可能会破坏可重复读。
  3.           举个例子：
  5. @Override
  6.     @Transactional
  7.     @CacheEvict(value="user",allEntries=true)
  8.     public void updateTest(String username) throws Exception{
  9.         UserVo vo=new UserVo();
  10.         vo.setLoginname("super");
  11.         vo.setUsername(username);
  12.         vo.setDeptId("c5145caa-fc06-11e5-8d93-1d3ee1acb99b");
  13.         vo.setPhone("test");
  14.         vo.setUserRole("0");
  15.         vo.setId("1");
  16.         userMapper.update(vo);
  17. }
  19.         updateTest方法修改数据库的同时，会清空所有的缓存
  21. @Cacheable(value="user",keyGenerator="baseCacheKeyGenerator")
  22.     public Json getUser(String userId){
  23.         System.out.println("no cache");
  24.         Optional<Json> json=Optional.of(new Json());
  25.         UserVo vo=userMapper.findUserById(userId);
  26.         Optional.ofNullable(vo).map(v -> {
  27.             v.setId(UUID.randomUUID().toString());
  28.             return v;
  29.         });
  30.         Optional.ofNullable(vo).ifPresent(json.get() :: setObj);
  31.         return json.get();
  32.     }
  34.           getUser会把相同userId的缓存起来。其中baseCacheKeyGenerator的策略为类，方法名，参数hash code值均相等才被视为同一查询。
  38. @Override
  39.     @Transactional
  40.     public Json doSomething(UserVo vo) throws Exception {
  41.         Json json=userService.getUser("1");
  42.         Optional.ofNullable(json).ifPresent(j -> {
  43.             Optional.ofNullable((UserVo) j.getObj()).ifPresent(v -> {
  44.                 System.out.println(v.getUsername());
  45.             });
  46.         });
  47.         java.util.concurrent.TimeUnit.SECONDS.sleep(10);
  48.         json=userService.getUser("1");
  49.         Optional.ofNullable(json).ifPresent(j -> {
  50.             Optional.ofNullable((UserVo) j.getObj()).ifPresent(v -> {
  51.                 System.out.println(v.getUsername());
  52.             });
  53.         });
  54.         return new Json();
  55.     }
  57.            doSomething方法会调用getUser两次，其中间隔10秒，在10秒之中，另外一个事务开启，调用updateTest方法，将该用户的username改为test。
  59.           当getUser没有缓存id为1的用户的时候，结果如下：

Center 2 

  1.           发现两次都没有走缓存，获得的结果一致，不存在不可重复读问题。
  3.           原因：第一次查询由于没有缓存，所有从数据库查询。接着该用户名被另一事务修改，并且清空缓存。第二次查询时由于缓存被清空，所以同样通过数据库查询，这时候事务的隔离等级Repeatable read起作用，还是获得事务开始前的用户名。
  8.           这个时候，如果我们再一次调用doSomething方法，并在第一次查询结束的10秒类，通过另一个事务调用updateTest方法，将该用户的username改为super。
  10.          结果如下：

Center 3

  1.             可以看到，第一次查询因为有缓存，所以直接从缓存中取，获得用户名为super，这个时候由于没有从数据库查询，所以不属于可重复读的第一次查询。然后修改username为test，并且清空了缓存。再次查询的时候，由于没有缓存，所以通过数据库第一次查询用户名为test。这样就造成了可重复读的破坏。可以推导出，如果这个时候再次修改用户为super，然后在之前的事务再查询用户名，这个时候事务的可重复读才会生效，因为这里的第三次查询被认为了第二次查询，将返回用户名为test。  
  7.              以上就是这次总结中事务的全部内容，对于存在坑的地方，使用一定要小心。

发表评论

表情：
评论列表 （有 0 条评论，391人围观）

还没有评论，来说两句吧...

相关阅读

    相关 Hibernate 的那些坑

    昨天下午，同事在开发的过程中遇到一个奇怪的问题：在控制器方法中查询出了一个对象，然后把这个对象传递到 service 层中，修改这个对象最后保存，但保存之后在数据库中相应的记录

    傷城~傷城~/ 0 赞/ 333 阅读