Spring事务遇Hibernate StaleObjectStateException未回滚问题

结合你的代码结构和并发场景，我来逐一分析可能的问题点和对应的解决办法：

一、最可能的原因：同类方法调用导致事务注解失效 #

如果methodA和methodB属于同一个类，那这就是典型的Spring事务代理失效问题：
Spring的事务是基于动态代理实现的，当同一个类内部的方法互相调用时，不会经过代理对象，直接调用的是原始类的方法，因此methodB上的@Transactional(propagation = Propagation.REQUIRES_NEW)注解根本不会生效。
这种情况下，methodB和methodC都会使用methodA的事务上下文（而methodA本身没有事务注解），相当于没有开启事务，自然不会触发回滚。

解决办法： #

• 拆分类：把methodB和methodC抽离到单独的Service类中，通过Spring注入的方式调用（比如在当前类中注入NewTransactionService，然后调用newTransactionService.methodB()），这样会触发代理逻辑，事务注解生效。
• 使用代理对象调用自身方法：
  1. 在当前类中注入自身的代理对象：

     @Autowired
     private YourService self;
     

     然后在methodA中调用self.methodB()代替直接调用methodB()。
  2. 或者开启expose-proxy=true，通过AopContext获取代理对象：

     // 先在配置类或启动类添加@EnableAspectJAutoProxy(exposeProxy = true)
     ((YourService) AopContext.currentProxy()).methodB();
     

二、异常被意外处理或类型不匹配 #

虽然你在methodB和methodC的rollbackFor中指定了异常类型，但仍可能存在以下问题：

• methodC抛出的异常被中间层包装成了其他类型（比如某些框架会将JPA异常包装成自定义异常），导致Spring无法识别到需要回滚的异常。
• 虽然你在methodA中捕获了异常，但如果methodB的事务代理生效的话，异常应该在methodB执行完毕后就触发回滚，不过如果异常被methodB内部的隐藏逻辑捕获（比如你没贴出来的代码），也会导致回滚失败。

解决办法： #

• 打印异常堆栈：在methodA的catch块中打印完整的异常堆栈ex.printStackTrace()，确认实际抛出的异常类型是否在rollbackFor列表中。
• 扩大回滚范围：可以将rollbackFor设置为Exception.class（你已经这么做了），确保所有异常都能触发回滚；或者直接使用rollbackFor = Throwable.class覆盖所有错误类型。
• 确保异常不被拦截：检查methodB内部是否有try-catch逻辑吃掉了异常，如果有，需要将异常重新抛出（比如throw ex;）。

三、事务管理器配置问题 #

如果事务注解生效但仍不回滚，需要检查事务管理器的配置：

• txManager是否正确关联了目标数据源，是否存在多数据源场景下选错事务管理器的情况。
• 事务管理器是否被自定义配置修改了回滚规则（比如某些配置会设置仅回滚特定异常）。

解决办法： #

• 验证txManager的配置，确保它管理的是你操作实体对应的数据源。
• 可以在methodB中添加日志，打印当前事务状态：

  System.out.println("当前是否有活跃事务：" + TransactionSynchronizationManager.isActualTransactionActive());
  System.out.println("事务名称：" + TransactionSynchronizationManager.getCurrentTransactionName());
  

  确认事务确实被正确开启。

四、并发场景下的特殊情况 #

在你的并发场景中，R1和R2同时执行时，可能其中一个请求的事务已经提交，另一个的乐观锁异常触发，但如果事务没开启，自然不会回滚。解决了前面的事务生效问题后，这个场景下的回滚应该能正常触发。

内容的提问来源于stack exchange，提问作者varkashy