如何判断@Transactional事务已标记回滚？代码场景问题咨询

代码结构 #

@Transactional
void A(){
    B();
    // 能否在这里判断事务是否已标记回滚？
    APICall(); // 事务失败时不应调用此API
}


void B(){
   try{
       C(); // 抛出NullPointerException
    }catch(Exception e){
        // 记录日志详情
    }
}

@Transactional
void C(){
   D(); // 抛出NullPointerException
}

核心问题 #

方法A()中的APICall()不该在事务失败时被调用。因为C()没捕获D()抛出的NullPointerException，C()的事务会回滚，进而把外层A()的事务也标记成回滚状态。但B()把异常抓了，导致A()继续执行并调用APICall()，可最后A()的事务还是会回滚，这就出现了不必要的API调用。

想问：能不能在A()里检查事务是否已经被标记回滚，从而跳过APICall()？还是只能在B()里把捕获的异常重新抛出去？

方案一：在A()里直接检查事务状态 #

可以用Spring提供的TransactionSynchronizationManager来获取当前事务的状态，判断是否已经被标记为回滚。代码改法如下：

import org.springframework.transaction.support.TransactionSynchronizationManager;

@Transactional
void A(){
    B();
    
    // 先判断当前事务是否存在，再检查回滚标记
    if (TransactionSynchronizationManager.isActualTransactionActive()) {
        boolean isRollbackOnly = TransactionSynchronizationManager.getCurrentTransactionStatus().isRollbackOnly();
        if (!isRollbackOnly) {
            APICall();
        }
    } else {
        // 如果没有活跃事务，根据业务需求决定是否调用API
        // APICall();
    }
}

注意事项：

• 必须依赖Spring的事务API，项目得引入Spring事务相关包。
• 要先判断是否有活跃事务，不然getCurrentTransactionStatus()会抛异常。

方案二：在B()里重新抛出异常 #

这是更贴合事务设计逻辑的做法。既然C()的异常会导致事务回滚，说明这是个会影响业务结果的严重错误，不该被B()悄悄吞掉。修改B()的代码：

void B() throws Exception {
   try{
       C();
    }catch(Exception e){
        // 先记录日志
        throw e; // 把异常抛出去，让A()知道出错了
    }
}

然后调整A()的逻辑：

@Transactional
void A(){
    try {
        B();
        // 只有B()执行成功，才调用API
        APICall();
    } catch (Exception e) {
        // 可以在这里统一处理异常，比如补充日志
    }
}

这种方案的优势：

• 逻辑更直白，符合“出错就中断流程”的直觉，避免后续做无用功。
• 不需要依赖事务状态的检查，代码可读性更高。

方案选择建议 #

• 如果B()里捕获的异常中，只有部分会导致事务回滚，其他异常不影响后续流程，那可以结合两种方案：要么在B()里只抛出会触发事务回滚的异常，要么在A()里检查事务状态。
• 优先推荐方案二，因为它更符合事务的语义——事务被标记回滚，说明业务已经出了不可修复的问题，这时候中断后续操作才是合理的。

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