@Transaction注解失效的⼏种场景
⼀、@Transactional介绍
1、@Transactional注解可以作⽤于哪些地⽅？
  @Transactional 可以作⽤在接⼝、类、类⽅法上。
作⽤于类：表⽰所有该类的public⽅法都配置相同的事务属性信息。
作⽤于⽅法：当类配置了@Transactional，⽅法也配置了@Transactional，⽅法的事务会覆盖类的事务配置信息。
作⽤于接⼝：不推荐这种使⽤⽅法，因为⼀旦标注在Interface上并且配置了Spring AOP 使⽤CGLib动态代理，将会导致
@Transactional注解失效。
2、@Transactional注有哪些属性？
  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.DEFAULT。
Isolation.DEFAULT：默认值，表⽰使⽤底层数据库的默认隔离级别。对⼤部分数据库⽽⾔，通常这值就是：
READ_COMMITTED，Mysql为REPEATABLE_READ。
Isolation.READ_UNCOMMITTED：该隔离级别表⽰⼀个事务可以读取另⼀个事务修改但还没有提交的数据。该级别不能防⽌脏读和不可重复读，因此很少使⽤该隔离级别。
Isolation.READ_COMMITTED：该隔离级别表⽰⼀个事务只能读取另⼀个事务已经提交的数据。该级别可以防⽌脏读，这也是⼤多数情况下的推荐值。
Isolation.REPEATABLE_READ：该隔离级别表⽰⼀个事务在整个过程中可以多次重复执⾏某个查询，并且每次返回的记录都相同。即使在多次查询之间有新增的数据满⾜该查询，这些新增的记录也会被忽略。该级别可以防⽌脏读和不可重复读。
Isolation.SERIALIZABLE：所有的事务依次逐个执⾏，这样事务之间就完全不可能产⽣⼲扰，也就是说，该级别可以防⽌脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会⽤到该级别。
  timeout：事务的超时时间，默认值为 -1。如果超过该时间限制但事务还没有完成，则⾃动回滚事务。
  readOnly：指定事务是否为只读事务，默认值为 false；为了忽略那些不需要事务的⽅法，⽐如读取数据，可以设置 read-only 为 true。
  rollbackFor：⽤于指定能够触发事务回滚的异常类型，可以指定多个异常类型。
  noRollbackFor：抛出指定的异常类型，不回滚事务，也可以指定多个异常类型。
⼆、@Transactional失效场景
1.@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.Modifiers())) {
return null;
}
此⽅法会检查⽬标⽅法的修饰符是否为 public，不是 public则不会获取@Transactional 的属性配置信息。注意：protected、private 修饰的⽅法上使⽤ @Transactional 注解，虽然事务⽆效，但不会有任何报错，这是我们很容犯错的⼀点。
2、@Transactional 注解属性 propagation 设置错误
这种失效是由于配置错误，若是错误的配置以下三种 propagation，事务将不会发⽣回滚。
TransactionDefinition.PROPAGATION_SUPPORTS：如果当前存在事务，则加⼊该事务；如果当前没有事务，则以⾮事务的⽅式继续运⾏。
TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以⾮事务⽅式运⾏，如果当前存在事务，则把当前事务挂起。TransactionDefinition.PROPAGATION_NEVER：以⾮事务⽅式运⾏，如果当前存在事务，则抛出异常。
3、@Transactional 注解属性 rollbackFor 设置错误
rollbackFor 可以指定能够触发事务回滚的异常类型。
Spring默认抛出了未检查unchecked异常（继承⾃ RuntimeException 的异常）或者 Error才回滚事务；其他异常不会触发回滚事务。
spring aop应用场景如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定rollbackFor属性。
// 希望⾃定义的异常可以进⾏回滚
@Transactional(propagation= Propagation.REQUIRED,rollbackFor= MyException.class
若在⽬标⽅法中抛出的异常是 rollbackFor 指定的异常的⼦类，事务同样会回滚。Spring源码如下：
private int getDepth(Class<?> exceptionClass, int depth) {
if (Name().ptionName)) {
// Found it!
return depth;
}
// If we've gone as far as we can go and haven't
if (exceptionClass == Throwable.class) {
return -1;
}
return Superclass(), depth + 1);
}
4、同⼀个类中⽅法调⽤，导致@Transactional失效
开发中避免不了会对同⼀个类⾥⾯的⽅法调⽤，⽐如有⼀个类Test，它的⼀个⽅法A，A再调⽤本类的⽅法B（不论⽅法B是⽤public还是private修饰），但⽅法A没有声明注解事务，⽽B⽅法有。则外部调⽤⽅法A之后，⽅法B的事务是不会起作⽤的。这也是经常犯错误的⼀个地⽅。那为啥会出现这种情况？其实这还是由于使⽤Spring AOP代理造成的，因为只有当事务⽅法被当前类以外的代码调⽤时，才会由Spring⽣成的代理对象来管理。
public void A() throws Exception {
/**
* 调⽤B⽅法
*/
this.B();
... ...
}
@Transactional()
public void B() throws Exception {
mapper.insert();
}
5、异常被你的 catch“吃了”导致@Transactional失效
这种情况是最常见的⼀种@Transactional注解失效场景
如果A⽅法调⽤了B⽅法，B⽅法内部抛了异常，⽽A⽅法此时try catch了B⽅法的异常，事务不能正常回滚。
因为当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反倒会画蛇添⾜。
6、数据库引擎不⽀持事务
这种情况出现的概率并不⾼，事务能否⽣效数据库引擎是否⽀持事务是关键。常⽤的MySQL数据库默认使⽤⽀持事务的innodb引擎。⼀旦数据库引擎切换成不⽀持事务的myisam，那事务就从根本上失效了。