spring事务失效的几种场景以及原因

如题所述

第1个回答  2022-08-15

spring事务失效场景可能大家在很多文章都看过了,所以今天就水一篇,看大家能不能收获一些不一样的东西。直接进入主题

失效原因: spring事务生效的前提是,service必须是一个bean对象
解决方案: 将service注入spring

失效原因: spring默认只会回滚非检查异常和error异常
解决方案: 配置rollbackFor

失效原因: spring事务只有捕捉到了业务抛出去的异常,才能进行后续的处理,如果业务自己捕获了异常,则事务无法感知
解决方案:
1、将异常原样抛出;
2、设置TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

失效原因: spring事务切面的优先级顺序最低,但如果自定义的切面优先级和他一样,且自定义的切面没有正确处理异常,则会同业务自己捕获异常的那种场景一样
解决方案:
1、在切面中将异常原样抛出;
2、在切面中设置TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

失效原因: spring事务默认生效的方法权限都必须为public

解决方案:
1、将方法改为public;
2、修改TansactionAttributeSource,将publicMethodsOnly改为false【这个从源码跟踪得出结论】
3、开启 AspectJ 代理模式【从spring文档得出结论】

具体步骤:

1、在pom引入aspectjrt坐标以及相应插件

2、在启动类上加上如下配置

注: 如果是在idea上运行,则需做如下配置


4、直接用TransactionTemplate

示例:

失效原因: 子容器扫描范围过大,将未加事务配置的serivce扫描进来

解决方案:
1、父子容器个扫个的范围;
2、不用父子容器,所有bean都交给同一容器管理

注: 因为示例是使用springboot,而springboot启动默认没有父子容器,只有一个容器,因此就该场景就演示示例了

失效原因: 因为spring事务是用动态代理实现,因此如果方法使用了final修饰,则代理类无法对目标方法进行重写,植入事务功能

解决方案:
1、方法不要用final修饰

失效原因: 原因和final一样

解决方案:
1、方法不要用static修饰

失效原因: 本类方法不经过代理,无法进行增强

解决方案:
1、注入自己来调用;
2、使用@EnableAspectJAutoProxy(exposeProxy = true) + AopContext.currentProxy()

失效原因: 因为spring的事务是通过数据库连接来实现,而数据库连接spring是放在threadLocal里面。同一个事务,只能用同一个数据库连接。而多线程场景下,拿到的数据库连接是不一样的,即是属于不同事务

失效原因: 使用的传播特性不支持事务

失效原因: 使用了不支持事务的存储引擎。比如mysql中的MyISAM

注: 因为springboot,他默认已经开启事务管理器。org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration。因此示例略过

失效原因: 当代理类的实例化早于AbstractAutoProxyCreator后置处理器,就无法被AbstractAutoProxyCreator后置处理器增强

本文列举了14种spring事务失效的场景,其实这14种里面有很多都是归根结底都是属于同一类问题引起,比如因为动态代理原因、方法限定符原因、异常类型原因等

https://github.com/lyb-geek/springboot-learning/tree/master/springboot-transaction-invalid-case

相似回答