关于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生效：

// 在userservice中通过this调用public的createuserpublic
[23:04:30.748] [http-nio-45678-exec-5] [debug] [o.s.orm.jpa.jpatransactionmanager:370 ] - 
creating new transaction with name [org.springframework.data.jpa.repository.support.simplejparepository.save]: 
propagation_required,isolation_default

[debug] [o.s.orm.jpa.jpatransactionmanager       :370 ] - creating new transaction with name [org.springframework.data.jpa.repository.support.simplejparepository.save]: propagation_required,isolation_default
//在controller中通过注入的userservice bean调用createuserpublic
[10:10:47.750] [http-nio-45678-exec-6] [debug] [o.s.orm.jpa.jpatransactionmanager       :370 ] - creating new transaction with name [org.geekbang.time.commonmistakes.transaction.demo1.userservice.createuserpublic]: propagation_required,isolation_default

这种实现在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。

以上就是关于spring的@transaction导致数据库回滚全部生效问题(又删库跑路)的详细内容，更多关于spring @transaction数据库回滚的资料请关注其它相关文章！