一口气说出6种，@Transactional注解的失效场景

• 引言
• 昨天公众号粉丝咨询了一个问题，说本身以前面试被问 @Transactional 注解哪些场景下会失效，一时语塞导致面试失败。因此今天简单的和你们分享一下 @Transactional 相关的知识。
• @Transactional 注解相信你们并不陌生，平时开发中很经常使用的一个注解，它能保证方法内多个数据库操做要么同时成功、要么同时失败。使用@Transactional 注解时须要注意许多的细节，否则你会发现 @Transactional 老是莫名其妙的就失效了。
• 事务
• 事务管理在系统开发中是不可缺乏的一部分，Spring 提供了很好事务管理机制，主要分为编程式事务和声明式事务两种。
• 编程式事务：是指在代码中手动的管理事务的提交、回滚等操做，代码侵入性比较强，以下示例：

try { 
	//TODO something 
	transactionManager.commit(status);
	} catch (Exception e) { 
	transactionManager.rollback(status); 
	throw new InvoiceApplyException("异常失败");
}

• 声明式事务：基于 AOP 面向切面的，它将具体业务与事务处理部分解耦，代码侵入性很低，因此在实际开发中声明式事务用的比较多。声明式事务也有两种实现方式，一是基于 TX 和 AO P的 xml 配置文件方式，二种就是基于 @Transactional 注解了。

@Transactional 
    @GetMapping("/test") 
    public String test() { 
        int insert = cityInfoDictMapper.insert(cityInfoDict); 
    }

• @Transactional 介绍
• @Transactional 注解能够做用于哪些地方？
• @Transactional 能够做用在接口、类、类方法。
  • 做用于类：当把 @Transactional 注解放在类上时，表示全部该类的 public 方法都配置相同的事务属性信息。
  • 做用于方法：当类配置了 @Transactional ，方法也配置了 @Transactional ，方法的事务会覆盖类的事务配置信息。

做用于接口：不推荐这种使用方法，由于一旦标注在 Interface 上而且配置了 Spring AOP 使用CGLib动态代理，将会致使 @Transactional 注解失效

@Transactional
    @RestController
    @RequestMappingpublic 
    class MybatisPlusController { 
        @Autowired private CityInfoDictMapper cityInfoDictMapper; 
        @Transactional(rollbackFor = Exception.class) 
        @GetMapping("/test") 
        public String test() throws Exception { 
            CityInfoDict cityInfoDict = new CityInfoDict(); 
            cityInfoDict.setParentCityId(2); 
            cityInfoDict.setCityName("2"); 
            cityInfoDict.setCityLevel("2"); 
            cityInfoDict.setCityCode("2"); 
            int insert = cityInfoDictMapper.insert(cityInfoDict); 
            return insert + ""; 
        }
    };

• @Transactional 注有哪些属性？
• propagation 属性
• propagation 表明事务的传播行为，默认值为 Propagation.REQUIRED，其余的属性信息以下：
  • Propagation.REQUIRED：若是当前存在事务，则加入该事务，若是当前不存在事务，则建立一个新的事务。( 也就是说若是 A 方法和 B 方法都添加了注解，在默认传播模式下，A 方法内部调用 B 方法，会把两个方法的事务合并为一个事务 ）
  • Propagation.SUPPORTS：若是当前存在事务，则加入该事务；若是当前不存在事务，则以非事务的方式继续运行。
  • Propagation.MANDATORY：若是当前存在事务，则加入该事务；若是当前不存在事务，则抛出异常。
  • Propagation.REQUIRES_NEW：从新建立一个新的事务，若是当前存在事务，暂停当前的事务。( 当类 A 中的  a 方法用默认 Propagation.REQUIRED 模式，类B中的  b 方法加上采用 Propagation.REQUIRES_NEW模式，而后在  a  方法中调用 b方法操做数据库，然而  a 方法抛出异常后，b 方法并无进行回滚，由于 Propagation.REQUIRES_NEW 会暂停  a 方法的事务 )
  • Propagation.NOT_SUPPORTED：以非事务的方式运行，若是当前存在事务，暂停当前的事务。
  • Propagation.NEVER：以非事务的方式运行，若是当前存在事务，则抛出异常。
  • Propagation.NESTED ：和 Propagation.REQUIRED 效果同样。isolation 属性
• isolation ：事务的隔离级别，默认值为 Isolation.DEFAULT。
• Isolation.DEFAULT：使用底层数据库默认的隔离级别。Isolation.READ_UNCOMMITTEDIsolation.READ_COMMITTEDIsolation.REPEATABLE_READIsolation.SERIALIZABLEtimeout 属性
• timeout ：事务的超时时间，默认值为 -1。若是超过该时间限制但事务尚未完成，则自动回滚事务。
• readOnly 属性
• readOnly ：指定事务是否为只读事务，默认值为 false；为了忽略那些不须要事务的方法，好比读取数据，能够设置 read-only 为 true 。
• rollbackFor 属性
• rollbackFor ：用于指定可以触发事务回滚的异常类型，能够指定多个异常类型。
• noRollbackFor 属性**
• noRollbackFor：抛出指定的异常类型，不回滚事务，也能够指定多个异常类型。
• ------------------------------华丽的分割线----------------------------------
• @Transactional 失效场景
• 接下来咱们结合具体的代码分析一下哪些场景下，@Transactional 注解会失效。
• @Transactional 应用在非 public 修饰的方法上
• 若是 Transactional 注解应用在非 public 修饰的方法上，Transactional 将会失效。

• 之因此会失效是由于在 Spring AOP 代理时，如上图所示 TransactionInterceptor （事务拦截器）在目标方法执行先后进行拦截，DynamicAdvisedInterceptor（CglibAopProxy 的内部类）的 intercept 方法或 JdkDynamicAopProxy 的 invoke 方法会间接调用 AbstractFallbackTransactionAttributeSource 的 computeTransactionAttribute 方法，获取 Transactional 注解的事务配置信息。

protected TransactionAttribute computeTransactionAttribute(Method method, Class<?> targetClass) {
        // Don't allow no-public methods as required. 
        if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) { 
            return null;
        }
    }

• 此方法会检查目标方法的修饰符是否为 public，不是 public则不会获取@Transactional 的属性配置信息。
• 注意：protected、private 修饰的方法上使用 @Transactional 注解，虽然事务无效，但不会有任何报错，这是咱们很容犯错的一点。
• @Transactional 注解属性 propagation 设置错误
• 这种失效是因为配置错误，如果错误的配置如下三种 propagation ，事务将不会发生回滚。
  • TransactionDefinition.PROPAGATION_SUPPORTS：若是当前存在事务，则加入该事务；若是当前没有事务，则以非事务的方式继续运行。
  • TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事务方式运行，若是当前存在事务，则把当前事务挂起。
  • TransactionDefinition.PROPAGATION_NEVER：以非事务方式运行，若是当前存在事务，则抛出异常。
• @Transactional 注解属性 rollbackFor 设置错误
  • rollbackFor 能够指定可以触发事务回滚的异常类型。
  • Spring 默认抛出了未检查 unchecked 异常（继承自 RuntimeException 的异常）或者 Error 才回滚事务；
  • 其余异常不会触发回滚事务。若是在事务中抛出其余类型的异常，但却指望 Spring 可以回滚事务，就须要指定 rollbackFor 属性。

• 但愿自定义的异常能够进行回滚

@Transactional(propagation= Propagation.REQUIRED,rollbackFor= MyException.class）

• 若在目标方法中抛出的异常是 rollbackFor 指定的异常的子类，事务一样会回滚。Spring 源码以下：

private int getDepth(Class<?> exceptionClass, int depth) {
        if (exceptionClass.getName().contains(this.exceptionName)) {
            // Found it!
            return depth;
        }
            // If we've gone as far as we can go and haven't found it...
        if (exceptionClass == Throwable.class) {
            return -1;
        }
        return getDepth(exceptionClass.getSuperclass(), depth + 1);
    }

• 同一个类中方法调用，致使 @Transactional 失效
• 开发中避免不了会对同一个类里面的方法调用，好比有一个类 Test，它的一个方法 A ，A 再调用本类的方法B（不论方法 B 是用 public 仍是 private 修饰），但方法 A 没有声明注解事务，而 B 方法有。则外部调用方法 A 以后，方法B的事务是不会起做用的。这也是常常犯错误的一个地方。
• 那为啥会出现这种状况？其实这仍是因为使用 Spring AOP 代理形成的，由于只有当事务方法被当前类之外的代码调用时，才会由 Spring 生成的代理对象来管理。

@Transactional 
    @GetMapping("/test") 
    private Integer A() throws Exception { 
        CityInfoDict cityInfoDict = new CityInfoDict(); 
        cityInfoDict.setCityName("2"); 
        /** * B 插入字段为 3的数据 */ 
        this.insertB(); 
        /** * A 插入字段为 2的数据 */ 
        int insert = cityInfoDictMapper.insert(cityInfoDict); 
        return insert; 
    } 
    @Transactional() 
    public Integer insertB() throws Exception { 
        CityInfoDict cityInfoDict = new CityInfoDict(); 
        cityInfoDict.setCityName("3"); 
        cityInfoDict.setParentCityId(3); 
        return cityInfoDictMapper.insert(cityInfoDict); 
    }

• 异常被你的 catch“吃了”致使 @Transactional 失效
  • 这种状况是最多见的一种 @Transactional 注解失效场景，

@Transactional 
    private Integer A() throws Exception { 
        int insert = 0; 
        try { 
            CityInfoDict cityInfoDict = new CityInfoDict(); 
            cityInfoDict.setCityName("2"); 
            cityInfoDict.setParentCityId(2); 
            /** * A 插入字段为 2的数据 */ 
            insert = cityInfoDictMapper.insert(cityInfoDict); 
            /** * B 插入字段为 3的数据 */ 
            b.insertB(); 
        } catch (Exception e) { 
            e.printStackTrace(); 
        } 
    }

• 若是 B 方法内部抛了异常，而 A 方法此时 try catch 了 B 方法的异常，那这个事务还能正常回滚吗？
  • 答案：不能！
• 会抛出异常：
  • org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
• 由于当 ServiceB 中抛出了一个异常之后，ServiceB 标识当前事务须要 rollback。可是 ServiceA 中因为你手动的捕获这个异常并进行处理，ServiceA 认为当前事务应该正常 commit 。此时就出现了先后不一致，也就是由于这样，抛出了前面的 UnexpectedRollbackException 异常。
• spring 的事务是在调用业务方法以前开始的，业务方法执行完毕以后才执行commit or rollback，事务是否执行取决因而否抛出 runtime 异常。若是抛出runtime exception 并在你的业务方法中没有 catch 到的话，事务会回滚。
• 在业务方法中通常不须要 catch 异常，若是非要 catch 必定要抛出 throw new RuntimeException()，或者注解中指定抛异常类型@Transactional(rollbackFor=Exception.class)，不然会致使事务失效，数据 commit 形成数据不一致，因此有些时候 try catch 反倒会多此一举。
• 数据库引擎不支持事务
• 这种状况出现的几率并不高，事务可否生效数据库引擎是否支持事务是关键。经常使用的 MySQL 数据库默认使用支持事务的 innodb 引擎。一旦数据库引擎切换成不支持事务的 myisam ，那事务就从根本上失效了。
• 总结
  • @Transactional 注解的看似简单易用，但若是对它的用法只知其一;不知其二，仍是会踩到不少坑的。