接手了个项目，还没动手同事就跟我说接口报事务回滚异常

前言

接收了一个项目，还没来得及修改，就有小伙伴B说调我的接口报事务回滚异常的错误。遇事不决，量子力学，甩个个锅先~（反正其它服务用这个接口好好的）

问题

虽然但是，还是得解决问题~把小伙伴B调用的日志和该服务接口日志都拉到本地地分析：

exception:org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

伴随着这个异常还有一堆SQL错误，这时候就明白了他传的字段字段值是有空值的，让他把这个值补上就先解决问题了。

不过，报SQL异常就算了，为啥会报事务回滚异常呢。问题还是出在羊身上。顺着异常提示，一路点过去，好家伙发现了罪魁祸首：

为了描述问题，这里简化一堆业务代码，可以看到这个方法上面的 @Transactional注解，并指定了需要回滚的异常，方法里还有try-catch，这样的设计也是可以理解的：try-cahch部分的代码不需要回滚，无try-catch部分的代码需要回滚。

 @Transactional(rollbackFor = Exception.class)
 public void updatel(AgentVo vo) {
       // 一堆的业务代码

        try {
          // 又是一堆的业务代码, 还调用了其它服务
            }
        } catch (Exception e) {
          // ...
        }
    }

而问题就是在try-cahch部分的代码，点开其中的调用，看到如下的实现：

@Transactional(rollbackFor = Exception.class)
public void modify(){
    // ...
}

顿时恍然大悟，@Transactional 的默认传播方式是啥？是我们的REQUIRED 嘞！

REQUIRED：业务方法需要在一个事务中运行，如果方法运行时，已处在一个事务中，那么就加入该事务，否则自己创建一个新的事务。

也就是说我们的 update 和 modify 方法是在同一个事务中，在 modify 方法中出现异常后，这个事务就被标记为需要回滚的状态了，然后回到update 方法，这个异常却是被catch住的，那么问题来了 update 方法中没被catch住的JDBC操作是要回滚还是提交呢，程序犯难了，抛出：

Transaction rolled back because it has been marked as rollback-only

解决

为了证实这种情况，简单写了个Demo并给出如下的解决方案：

#TestController
@RequestMapping("/test")
    @Transactional
    public String test() {
         // 其它JDBC操作
        try {
            testService.inner();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return "ok";
    }

#TestService 
@Transactional(rollbackFor = Exception.class)
    public void inner() {
        testDao.update();
        System.out.println(1/0);
    }

调用后，抛出异常：

针对这种场景：在一个方法中，可分为A、B两部份（或者多份）的业务操作，其中，A、B都要用事务保证ACID，而B还不会影响到A，如果是在设计之初，就不应该将它们划分到一个方法中去。

万一不幸遇到了也别慌，想想事务的隔离级别的REQUIRESNEW：

REQUIRESNEW：不管是否存在事务，该方法总会为自己发起一个新的事务。如果方法已经运行在一个事务中，则原有事务挂起，新的事务被创建。

REQUIRES_NEW

 @Transactional(propagation = REQUIRES_NEW, rollbackFor = Exception.class)
    public void inner(SignTemplate signTemplate) {
       // ...
    }

这种处理则要注意一种情况，那就是A、B的操作有交集，譬如我A中插入一条id为35的数据，随后在B中又对id为35的行进行更新。因为REQUIRESNEW下，原事务只是被挂起，还未提交，所以此时的更新操作会抛出锁等待超时的异常。

这里也模拟出来了：

手动设置

@Autowired
    private PlatformTransactionManager platformTransactionManager;
    @Autowired
    private TransactionDefinition transactionDefinition;

    @RequestMapping("/test")
    public String test() {
        TransactionStatus transaction = platformTransactionManager.getTransaction(transactionDefinition);
         // 其它JDBC操作
         platformTransactionManager.commit(transaction);
        try {
            testService.inner();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return "ok";
    }

@Transactional(rollbackFor = Exception.class)
    public void inner() {
       // ...
    }

Spring事务其它传播方式

除去上述的REQUIRED和 REQUIRESNEW，还有如下的方式：

• NOT_SUPPORTED：声明方法不需要事务。如果方法没有关联到一个事务，容器不会为他开启事务，如果方法在一个事务中被调用，该事务会被挂起，调用结束后，原先的事务会恢复执行。
• MANDATORY：该方法只能在一个已经存在的事务中执行，业务方法不能发起自己的事务。如果在没有事务的环境下被调用，容器抛出例外
• SUPPORTS：该方法在某个事务范围内被调用，则方法成为该事务的一部分。如果方法在该事务范围外被调用，该方法就在没有事务的环境下执行。
• NEVER：该方法绝对不能在事务范围内执行。如果在就抛异常。只有该方法没有关联到任何事务，才正常执行。
• NESTED：如果一个活动的事务存在，则运行在一个嵌套的事务中。如果没有活动事务，则按REQUIRED属性执行。它使用了一个单独的事务，这个事务拥有多个可以回滚的保存点。内部事务的回滚不会对外部事务造成影响。它只对DataSourceTransactionManager事务管理器起效。