EJB事务传播行为配置错误导致回滚异常

Question

在EJB应用中，事务传播行为配置错误是引发回滚异常的常见原因。典型问题如：将`REQUIRED`误配为`REQUIRES_NEW`，导致外层事务无法感知内层异常，从而破坏全局一致性。例如，无状态会话Bean的方法A调用方法B，若B配置为`REQUIRES_NEW`且抛出未检查异常，即使A捕获异常，B的事务已独立回滚，但A的事务可能继续提交，造成数据不一致。更严重时，因事务上下文传播混乱，容器抛出`TransactionRolledBackException`。正确理解`PROPAGATION`行为（如`REQUIRED`、`MANDATORY`、`NESTED`）并结合业务场景合理配置，是避免此类问题的关键。

Answer 1

一、事务传播行为的基本概念与EJB上下文

EJB（Enterprise JavaBeans）作为Java EE平台的核心组件之一，提供了声明式事务管理能力。其事务行为通过@TransactionAttribute注解或部署描述符进行配置，其中事务传播行为（Propagation Behavior）决定了当前方法执行时如何与已有事务上下文交互。

在EJB容器中，常见的传播行为包括：

• REQUIRED：若存在活动事务，则加入；否则新建一个事务。
• REQUIRES_NEW：无论是否有事务，都创建新事务，并暂停当前事务（如有）。
• MANDATORY：必须在已有事务中运行，否则抛出异常。
• NESTED：在现有事务内嵌套执行，支持回滚到保存点。
• SUPPORTS：支持当前事务，但不强制要求。
• NOT_SUPPORTED：以非事务方式执行，挂起现有事务。
• NEVER：绝对不能在事务中运行，否则报错。

二、典型错误场景分析：REQUIRED 误配为 REQUIRES_NEW

当开发人员将本应使用REQUIRED的方法错误地设置为REQUIRES_NEW时，会引发严重的事务一致性问题。以下是一个典型的调用链示例：

@Stateless
public class OrderService {
    
    @EJB
    private PaymentService paymentService;

    @TransactionAttribute(REQUIRED)
    public void placeOrder(Order order) {
        saveOrder(order); // 属于同一事务
        try {
            paymentService.processPayment(order.getPayment());
        } catch (RuntimeException e) {
            log.error("Payment failed, but order may still be saved");
            // 外层捕获异常，但内层事务已独立回滚
        }
    }
}

@Stateless
public class PaymentService {

    @TransactionAttribute(REQUIRES_NEW) // 错误配置！
    public void processPayment(Payment payment) {
        deductBalance(payment);
        throw new IllegalArgumentException("Invalid account"); // 模拟失败
    }
}
    

上述代码中，尽管placeOrder方法试图捕获支付异常并继续执行，但由于processPayment使用了REQUIRES_NEW，其事务独立提交或回滚，外层无法感知该事务的最终状态，导致订单保存而支付未完成，破坏了业务原子性。

三、事务上下文传播机制与异常传递路径

EJB容器通过线程绑定的事务上下文（Transaction Context）来管理事务边界。当方法调用跨越Bean边界时，容器依据传播行为决定是否共享或隔离事务。

传播行为	是否参与外层事务	异常是否影响外层	适用场景
REQUIRED	是	是	常规业务操作
REQUIRES_NEW	否（挂起）	仅当未被捕获时间接影响	日志记录、审计等独立操作
MANDATORY	强制参与	直接影响	子操作必须属于主事务
NESTED	是（保存点）	可控制回滚范围	复杂嵌套逻辑
SUPPORTS	视情况而定	弱关联	查询类操作

四、深度剖析 TransactionRolledBackException 的触发机制

当内层方法因REQUIRES_NEW独立回滚后，若外层方法继续尝试提交事务，容器会在提交阶段检测到资源状态不一致或事务完整性受损，进而抛出TransactionRolledBackException。这种异常通常出现在分布式事务（如XA事务）环境中，尤其是在使用JTA事务管理器时。

根本原因在于事务协调器（Transaction Coordinator）发现某个分支事务已标记为回滚，因此拒绝提交整个全局事务。

常见堆栈片段如下：

javax.transaction.TransactionRolledbackException: Transaction is marked for rollback
    at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:756)
    at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4532)
    ...
    

五、解决方案与最佳实践建议

为避免此类问题，应遵循以下原则：

1. 优先使用 REQUIRED：大多数业务方法应默认使用REQUIRED，确保事务统一性。
2. 谨慎使用 REQUIRES_NEW：仅用于明确需要独立事务的操作，如写日志、发送通知。
3. 启用 NESTED 支持：在支持保存点的数据库上，考虑使用嵌套事务实现细粒度回滚控制。
4. 统一异常处理策略：避免在事务方法中吞掉运行时异常，应合理抛出或转换为应用异常。
5. 利用 MANDATORY 约束调用上下文：对必须在事务中执行的方法标注MANDATORY，防止误用。
6. 结合AOP与监控工具：使用APM工具（如New Relic、SkyWalking）追踪事务跨度与边界。
7. 单元测试覆盖事务行为：通过Arquillian或TestContainers验证事务传播效果。
8. 文档化关键流程的事务设计：便于团队理解与维护。

六、可视化流程图：事务传播决策路径

graph TD A[方法被调用] --> B{是否存在活动事务?} B -- 是 --> C{传播行为是 REQUIRES_NEW?} B -- 否 --> D[启动新事务] C -- 是 --> E[挂起当前事务
创建新事务] C -- 否 --> F[加入当前事务] E --> G[执行方法] F --> G G --> H{发生未捕获异常?} H -- 是 --> I[当前事务标记回滚] H -- No --> J[提交事务] I --> K{是否为根事务?} K -- 是 --> L[整体回滚] K -- 否 --> M[通知上级事务]