@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()  设置手动回滚。
发布了68 篇原创文章 · 获赞 93 · 访问量 8496

猜你喜欢

转载自blog.csdn.net/qq_34707456/article/details/103661120