@Transactional失效场景及其原理分析

1.数据库引擎是否支持事务（Mysql的MyIsam引擎就不支持事务）

2.注解所在的类是否注入spring容器中

3.注解所在方法是否为public修饰或者final（方法实现了接口是否为public,方法没有实现接口是否为final)

分析：这是由 Spring AOP 的本质决定的。如果你在 protected、private 或者默认可见性的方法上使用 @Transactional 注解，这将被忽略，也不会抛出任何异常。

          @Transactional的实现是基于动态代理的，private和final修饰的方法，不会被代理。

          个人观点：在spring中动态代理分为jdk动态代理和cglib动态代理，jdk动态代理要求必须实现接口（所以方法必须是public的），但是cglib动态代理底层则是通过字节码生成被代理类的子类来实现的，这里要求被代理类必须能被继承（所以方法不能被final修饰--final可以限制类被继承）并且方法也只能是public,其他的权限修饰符在继承时访问权限会发生变化，例如protected的，在父类中为public,在子类中就为protected了。

 

4.所用数据源是否加载了事务管理器

5.是否发生了方法的自调用（同一个类中的A方法调用B方法）

分析：若同一类中的其他没有@Transactional 注解的方法内部调用有@Transactional 注解的方法，有@Transactional 注解的方法的事务被忽略，不会发生回滚。

 

6.当方法发生异常时，使用try catch捕获了异常，并且catch中没有抛出异常或者手动回滚。

分析：事务的回滚是方法发生异常，在aop的异常通知中进行拦截，回滚，如果方法中捕获了异常，是不会被aop的异常通知拦截到的。

      如果使用了try catch捕获异常，需要在catch中抛出一个异常或者在catch中通过

 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()  设置手动回滚。