又删库跑路!Spring 的 @Transaction 导致数据库回滚全部生效!
1 前言
很多需要使用事务的场景，都只是在方法上直接添加个@Transactional注解
但是，你以为这真的够了吗？
事务如果未达到完美效果，在开发和测试阶段都难以被发现，因为你难以考虑到太多意外场景。但当业务数据量发展，就可能导致大量数据不一致的问题，就会造成前人栽树后人踩坑，需要大量人力排查解决问题和修复数据。
2 如何确认 Spring 事务生效了？
使用@Transactional一键开启声明式事务， 这就真的事务生效了？过于信任框架总有“意外惊喜”。来看如下案例
领域层
实体
领域服务
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 进行调用。
但有时因没有正确处理异常，导致事务即便生效也不一定能回滚。
2 事务生效不代表能正确回滚
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属性。
4 总结
若要针对 private 方法启用事务，动态代理方式的 AOP 不可行，需要使用静态织入方式的 AOP，也就是在编译期间织入事务增强代码，可以配置 Spring 框架使用 AspectJ 来实现 AOP。
版权声明: 本文为 InfoQ 作者【JavaEdge】的原创文章。
原文链接:【http://xie.infoq.cn/article/f0028d832f212d4b653bdeb48】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
还未添加个人签名 2019.09.25 加入
还未添加个人简介
评论