使用 @Transactional 时常犯的 N 种错误
@Transactional
是我们在用 Spring 时候几乎逃不掉的一个注解,该注解主要用来声明事务。它的实现原理是通过 Spring AOP 在注解修饰方法的前后织入事务管理的实现语句,所以开发者只需要通过一个注解就能代替一系列繁琐的事务开始、事务关闭等重复性的编码任务。
编码方式确实简单了,但也因为隐藏了直观的实现逻辑,一些错误的编码方法可能会让@Transactional
注解失效,达不到事务的作用。最直接的表现就是:方法执行过程中抛出了异常,但事务没有回滚,最终导致了脏数据的产生。
之前我在博客上也写过一篇有趣的讨论我来出个题:这个事务会不会回滚?,当时很多人都给出了标准的错误答案,如果没看过的小伙伴不妨进去挑战一下?
虽然之前讨论了一些特殊情况,但还是一直有小伙伴会邮件、微信群里问一些关于事务失效的问题。主要还是@Transactional
声明事务失效的情况真的是多种多样!所以,今天写一篇总结一下,如果下次再碰到,那就打开这片文章,一个个顺下来看,是不是哪里写错了。当然可能这里还会有遗漏,所以如果你有其他错误案例,也可以告诉我,我会持续整理到这篇文章里。
1. 在同一个类中调用
错误案例:
这类错误适用于所有基于 Spring AOP 实现的注解,比如:《使用@Async实现异步调用》中提到的@Async
注解,《使用@Scheduled实现定时任务》中提到的@Scheduled
注解,还有Spring缓存注解的使用解中提到的@Cacheable
注解等。
解决这个问题的方法比较简单,还是合理规划好层次关系即可,比如这样:
注意:这里 A 类用了构造器注入 B 的实现(为什么没用@Autowrire
,可以看看前几天分享的这篇什么时候不要用@Autowired注入),构造函数用 Lombok 的@AllArgsConstructor
生成(这个不熟悉的话可以看看之前这篇Lombok:让JAVA代码更优雅)。
2. @Transactional 修饰方法不是 public
错误案例:
这也是基于 Spring AOP 实现的注解所要满足的要求。这个最简单,很好理解,也很直观,就不详细展开了。直接把方法访问类型改成public
即可。
3. 不同的数据源
错误案例:
有的时候,我们一个操作可能会同时写多个数据源,比如上面这个例子里的orderRepo1
和orderRepo2
是连接的两个不同数据源。默认情况下,这种跨数据源的事务是不会成功的。
如果要在多个数据源之间实现事务,那么可以引入 JTA,具体如何做的话可以看看之前的这篇分享《使用JTA实现多数据源的事务管理》
4. 回滚异常配置不正确
默认情况下,仅对RuntimeException
和Error
进行回滚。如果不是的它们及它们的子孙异常的话,就不会回滚。
所以,在自定义异常的时候,要做好适当的规划,如果要影响事务回滚,可以定义为RuntimeException
的子类;如果不是RuntimeException
,但也希望触发回滚,那么可以使用rollbackFor
属性来指定要回滚的异常。
5. 数据库引擎不支持事务
这个来源于一个读者反馈的例子,代码跟我的案例一摸一样,我这边是好的,但他就是不回滚。
后来排查出来是因为漏了一个关键属性的配置:
这里的spring.jpa.database-platform
配置主要用来设置 hibernate 使用的方言。这里特地采用了 MySQL5InnoDBDialect,主要为了保障在使用 Spring Data JPA 时候,Hibernate 自动创建表的时候使用 InnoDB 存储引擎,不然就会以默认存储引擎 MyISAM 来建表,而 MyISAM 存储引擎是没有事务的。
如果你的事务没有生效,那么可以看看创建的表,是不是使用了 MyISAM 存储引擎,如果是的话,那就是这个原因了!
小结
如果你看到最后,发现还有其他情况还没有囊括其中,欢迎告诉我们哟,我们会持续更新这篇文章!以帮助碰到此类问题的读者。
好了,今天的学习就到这里!如果您学习过程中如遇困难?可以加入我们超高质量的Spring技术交流群,参与交流与讨论,更好的学习与进步!
版权声明: 本文为 InfoQ 作者【程序猿DD】的原创文章。
原文链接:【http://xie.infoq.cn/article/7ba620c3401624e14314be119】。文章转载请联系作者。
评论