今日分享开始啦，请大家多多指教~

今天给大家分享的是你的数据库事务加上 Spring 的 @Transaction 注解为啥还没生效？事务如果未达到完美效果，在开发和测试阶段都难以被发现，因为你难以考虑到太多意外场景。但当业务数据量的发展，就可能导致大量数据不一致的问题，就会造成前人栽树后人踩坑，需要大量人力排查解决问题和修复数据。

很多需要使用事务的场景，都只是在方法上直接添加个 @Transactional 注解

但是，你以为这真的够了吗？

如何确认 Spring 事务生效了？

使用 @Transactional 一键开启声明式事务， 这就真的事务生效了？过于信任框架总有“意外惊喜”。来看如下案例：

领域层

用户实体

DAO 层

领域服务

• createUserError1 调用 private 方法

• createUserPrivate，被 @Transactional 注解。当传入的用户名包含 test 则抛异常，让用户的创建操作失败

• getUserCount

用户接口层

调用 UserService#createUserError1

• 测试结果

  
  

  即便用户名不合法，用户也能创建成功。刷新浏览器，多次发现有十几个的非法用户注册。

@Transactional 生效原则

public 方法

除非特殊配置（比如使用 AspectJ 静态织入实现 AOP），@Transactional 必须定义在 public 方法才生效。

因为 Spring 的 AOP，private 方法无法被代理到，自然也无法动态增强事务处理逻辑。

那简单，把 createUserPrivate 方法改为 public 不就行了。

但发现事务依旧未生效。

必须通过代理过的类从外部调用目标方法

要调用增强过的方法必然是调用代理后的对象。

尝试修改 UserService，注入一个 self，然后再通过 self 实例调用标记有 @Transactional 注解的 createUserPublic 方法。设置断点可以看到，self 是由 Spring 通过 CGLIB 方式增强过的类：

CGLIB 通过继承实现代理类，private 方法在子类不可见，所以无法进行事务增强。而 this 指针代表调用对象本身，Spring 不可能注入 this，所以通过 this 访问方法必然不是代理。

把 this 改为 self，这时即可验证事务生效：非法的用户注册操作可回滚。

虽然在 UserDomainService 内部注入自己调用自己的 createUserPublic 可正确实现事务，但这不符常规。更合理的实现方式是，让 Controller 直接调用之前定义的 UserService 的 createUserPublic 方法。

this/self/Controller 调用 UserDomainService

• this 自调用

  
  

  无法走到 Spring 代理类

• 后两种

  
  

  调用的 Spring 注入的 UserService，通过代理调用才有机会对 createUserPublic 方法进行动态增强。

推荐开发时打开 Debug 日志以了解 Spring 事务实现的细节。

比如 JPA 数据库访问，开启 Debug 日志：

logging.level.org.springframework.orm.jpa=DEBUG

开启日志后再比较下在 UserService 中 this 调用、Controller 中通过注入的 UserService Bean 调用 createUserPublic 的区别。

很明显，this 调用因没走代理，事务没有在 createUserPublic 生效，只在 Repository 的 save 生效：

这种实现在 Controller 里处理异常显得繁琐，还不如直接把 createUserWrong2 加 @Transactional 注解，然后在 Controller 中直接调用该方法。

这既能从外部（Controller 中）调用 UserService 方法，方法又是 public 的能够被动态代理 AOP 增强。

小结

务必确认调用被 @Transactional 注解标记的方法被 public 修饰，并且是通过 Spring 注入的 Bean 进行调用。

但有时因没有正确处理异常，导致事务即便生效也不一定能回滚。

事务生效不代表能正确回滚

AOP 实现事务：使用 try/catch 包裹 @Transactional 注解的方法：

• 当方法出现异常并满足一定条件，在 catch 里可设置事务回滚

• 没有异常则直接提交事务

一定条件

只有异常传播出了被 @Transactional 注解的方法，事务才能回滚。

Spring 的 TransactionAspectSupport#invokeWithinTransaction 就是在处理事务。观察源码得知，只有捕获到异常后才能进行后续事务处理：

默认情况下，出现 RuntimeException（非受检异常）或 Error，Spring 才会回滚事务。

Spring 的 DefaultTransactionAttribute：

• 受检异常一般是业务异常或类似另一种方法的返回值，出现这种异常可能业务还能完成，所以不会主动回滚

• 而 Error 或 RuntimeException 代表非预期结果

事务无法正常回滚的各种惨案

异常无法传播出方法

受检异常

注册的同时会有一次文件读，若读文件失败，希望用户注册的 DB 操作回滚。因读文件抛的是受检异常，createUserError2 传播出去的也是受检异常

以上方法虽然避开了事务不生效的坑，但因异常处理不当，导致异常时依旧不回滚事务。

修复回滚失败 bug

1 手动设置让当前事务处回滚态

若希望自己捕获异常并处理，可手动设置让当前事务处回滚态

查看日志，事务确定回滚。

Transactional code has requested rollback：手动请求回滚。

2 注解中声明，期望所有 Exception 都回滚事务

• 突破默认不回滚受检异常的限制

• 查看日志，提示回滚：

该案例有 DB 操作、IO 操作，在 IO 操作问题时期望 DB 事务也回滚，以确保逻辑一致性。

由于异常处理不正确，导致虽然事务生效，但出现异常时没回滚。

Spring 默认只对被 @Transactional 注解的方法出现 RuntimeException 和 Error 时回滚，所以若方法捕获了异常，就需要通过手写代码处理事务回滚。

若希望 Spring 针对其他异常也可回滚，可相应配置 @Transactional 注解的 rollbackFor 和 noRollbackFor 属性覆盖 Spring 的默认配置。

有些业务可能包含多次 DB 操作，不一定希望将两次操作作为一个事务，这时就需仔细考虑事务传播的配置。

3 事务传播配置是否符合业务逻辑

案例

用户注册：会插入一个主用户到用户表，还会注册一个关联的子用户。期望将子用户注册的 DB 操作作为一个独立事务，即使失败也不影响注册主用户的流程。

• UserService：创建主、子用户

• SubUserService：使子用户注册失败。期望子用户注册作为一个事务单独回滚而不影响注册主用户

• 启动调用后查看日志：事务回滚了

不对呀！因为运行时异常逃出被 @Transactional 注解的 createUserWrong，Spring 当然会回滚事务。若期望主方法不回滚，应捕获子方法所抛的异常。

修正方案

把 subUserService#createSubUserWithExceptionError 包上 catch，这样外层主方法 createUserError2 就不会出现异常

启动后查看日志注意到：

• 对 createUserError2 开启异常处理

• 子方法因出现运行时异常，标记当前事务为回滚

• 主方法捕获异常并打印 create sub user error

• 主方法提交事务

但 Controller 出现一个 UnexpectedRollbackException，异常描述提示最终该事务回滚了且为静默回滚：因 createUserError2 本身并无异常，只不过提交后发现子方法已把当前事务设为回滚，无法完成提交。

明明无异常发生，但事务也不一定可提交

因为主方法注册主用户的逻辑和子方法注册子用户的逻辑为同一事务，子逻辑标记了事务需回滚，主逻辑自然也无法提交。

那么修复方式就明确了，独立子逻辑的事务，即修正 SubUserService 注册子用户方法，为注解添加 propagation = Propagation.REQUIRES_NEW 设置 REQUIRES_NEW 事务传播策略。即执行到该方法时开启新事务，并挂起当前事务。

创建一个新事务，若存在则暂停当前事务。类似同名的 EJB 事务属性。

注：实际事务暂停不会对所有事务管理器外的开箱。 这特别适于 org.springframework.transaction.jta.JtaTransactionManager ，这就需要 javax.transaction.TransactionManager 被提供给它（这是服务器特定的标准 Java EE）

主方法无变化，依旧需捕获异常，防止异常外泄导致主事务回滚，重命名为 createUserRight：

修正后再查看日志

• Creating new transaction with name createUserRight

对 createUserRight 开启主方法事务

• createMainUser finish

创建主用户完成

• Suspending current transaction, creating new transaction with name createSubUserWithExceptionRight

主事务挂起，开启新事务，即对 createSubUserWithExceptionRight 创建子用户的逻辑

• Initiating transaction rollback

子方法事务回滚

• Resuming suspended transaction after completion of inner transaction

子方法事务完成，继续主方法之前挂起的事务

• create sub user error:invalid status

主方法捕获到了子方法的异常

• Committing JPA transaction on EntityManager

主方法的事务提交了，随后我们在 Controller 里没看到静默回滚异常

若方法涉及多次 DB 操作，并希望将它们作为独立事务进行提交或回滚，即需考虑细化配置事务传播方式，即配置 @Transactional 注解的 Propagation 属性。

总结

若要针对 private 方法启用事务，动态代理方式的 AOP 不可行，需要使用静态织入方式的 AOP，也就是在编译期间织入事务增强代码，可以配置 Spring 框架使用 AspectJ 来实现 AOP。

今日份分享已结束，请大家多多包涵和指点！