spring 事务应用误区总结：那些导致事务不回滚的坑

基于JDBC的 Spring事务在项目中常用来保证数据的一致性， 想要正确的使用，绝不是加一个@Transactional那么简单。最近团队内在排查事务不生效的问题时，就遇到了一个很典型的错误应用的场景。本文就几个容易遇到的导致事务不生效的场景做个总结。

一、Spring事务原理

在使用JDBC事务操作数据库时，流程如下：

Spring本身并不提供事务，而是对JDBC事务通过AOP做了封装，隐藏了2和4的操作，简化了JDBC的应用。

spring对JDBC事务的封装，是通过AOP动态代理来实现的，在调用目标方法(也就是第3步)前后会通过代理类来执行事务的开启、提交或者回滚操作。

注意关键词“动态代理”，这意味着要生成一个代理类，那么我们就不能在一个类内直接调用事务方法，否则无法代理，而且该事务方法必须是public，如果定义成 protected、private 或者默认可见性,则无法调用!

忽略这两点，则很容易误用spring事务!

二、Spring事务应用的坑

Spring事务的常见误用主要有两个：Service类内部方法调用、try…catch抛出checked异常。

我们先建一张User表和相关的dao类用来后续验证Spring事务的用法

Mobile长度定义为11位，下面的例子通过这个11为长度的限制来触发数据库操作的异常。

误区1. Service类内部方法调用

"199999933333"长度超过11位，会触发数据库异常，正常情况下会引起事务的回滚。 下面我们可以通过一个集成测试来验证一下该事务有没有生效。

执行dealUserRequesTest测试方法，会报如下的异常信息：

再看一下数据库，如果没有回滚，则user1的数据会被插入。

可见事务并没有触发。原因就在于Service类内部方法调用无法使得spring无法对目标类进行动态代理，导致事务无法生效。这是在日常开发中很容易犯的一个错误。

误区（2）：不合理的异常处理

对于第二个错误的应用，主要是原因对@Transactional注解的细节理解的不够全面。这个注解中有一个rollbackFor的属性需要特别关注，我们先看一下源码中的注解

默认情况下，spring事务只针对RuntimeException类型的unchecked异常才会触发回滚操作

我们通过下面的代码来验证一下：定义一个DataTooLongException的checked异常，对外抛出该异常。

"100000000000"长度超过11位，我们对batchAddUser做一个集成测试来验证一下事务是否会回滚。

执行该测试方法触发了以下异常：

我们去数据库看下user1的数据是否被写到了数据库：

这说明事务没有生效，没有触发回滚。

如果业务需要，一定要抛出checked异常的时候，可以通过rollbackFor属性指定异常类型即可。有兴趣的可以动手验证一下，这里不再赘述。

这两个spring事务应用的误区说到底还是对spring事务的实现理解不够深刻和全面，后面会再写一篇spring事务源码分析的文章来探讨一下具体是如何实现的。