Java EE中外层事务报错时，如何避免嵌套服务调用回滚且不触发死锁？

针对你的场景，下面是几种Java EE原生的可行方案，同时解决之前遇到的死锁和同步无效问题：

1. 正确使用EJB的@TransactionAttribute(REQUIRES_NEW) #

你之前用这个注解导致死锁，大概率是操作顺序或锁冲突问题，而非注解本身的问题。Java EE中EJB的REQUIRES_NEW会完全挂起当前事务，启动全新的独立事务，新事务的提交/回滚与原事务无关。

正确用法注意点： #

• Service B必须是独立的EJB（如@Stateless或@Singleton），且通过EJB容器注入调用，不能直接调用类的方法（否则注解不会生效）
• 排查死锁根源：查询Oracle的v$lock和v$session视图，确认死锁的资源是哪一行数据。如果Service A先锁定了某行，Service B用新事务再次请求锁定同一行，就会导致死锁。解决方式：
  • 调整操作顺序：让Service B的更新在Service A锁定数据之前执行
  • 避免操作同一行：如果业务允许，修改Service B的逻辑，不更新Service A正在操作的记录
  • 使用乐观锁：给表加版本字段，避免长时间持有行锁

代码示例： #

// Service B：独立EJB，使用REQUIRES_NEW
@Stateless
public class ServiceB {
    @PersistenceContext
    private EntityManager em;

    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public void performCleanupUpdate() {
        // 执行清理活动数据更新操作
        // em.merge(...) 或 em.createQuery(...)执行更新
    }
}

// Service A：注入Service B并调用
@Stateless
public class ServiceA {
    @Inject
    private ServiceB serviceB;

    public void processRequest() throws ExpectedBusinessException {
        // 业务逻辑执行
        serviceB.performCleanupUpdate(); // 这里会启动新事务，独立提交
        
        // 抛出预期业务异常，原事务回滚，但Service B的事务已提交
        throw new ExpectedBusinessException("合法业务场景错误");
    }
}

2. 手动控制UserTransaction #

如果EJB的事务注解方式仍有锁问题，可以直接通过UserTransaction手动挂起原事务，启动新事务执行更新：

@Stateless
public class ServiceB {
    @Resource
    private UserTransaction utx;
    @PersistenceContext
    private EntityManager em;

    public void performCleanupUpdate() throws Exception {
        Transaction suspendedTransaction = null;
        try {
            // 挂起当前事务（如果存在）
            suspendedTransaction = utx.suspend();
            
            // 启动新事务
            utx.begin();
            // 执行清理更新操作
            // ...
            utx.commit();
        } catch (Exception e) {
            if (utx.getStatus() == Status.STATUS_ACTIVE) {
                utx.rollback();
            }
            throw e;
        } finally {
            // 恢复原事务（如果之前有挂起的）
            if (suspendedTransaction != null) {
                utx.resume(suspendedTransaction);
            }
        }
    }
}

这种方式完全手动控制事务边界，灵活性更高，适合复杂场景。

3. JMS异步处理（最终一致性） #

如果业务允许最终一致而非实时持久化，可以用JMS异步解耦：

• Service A在抛出异常前，发送一条JMS消息到队列
• 实现一个消息驱动Bean（MDB）监听该队列，在MDB中执行Service B的清理更新操作
• MDB的事务是独立的，即使Service A的事务回滚，消息依然会被MDB消费并执行更新，完全隔离

代码示例： #

// Service A发送消息
@Stateless
public class ServiceA {
    @Resource(mappedName = "jms/CleanupQueue")
    private Queue cleanupQueue;
    @Inject
    private JMSContext jmsContext;

    public void processRequest() throws ExpectedBusinessException {
        // 业务逻辑
        jmsContext.createProducer().send(cleanupQueue, "cleanup-trigger");
        
        throw new ExpectedBusinessException("合法业务场景错误");
    }
}

// MDB处理消息，执行更新
@MessageDriven(mappedName = "jms/CleanupQueue")
public class CleanupMDB implements MessageListener {
    @PersistenceContext
    private EntityManager em;

    @Override
    public void onMessage(Message message) {
        // 执行清理活动数据更新操作
        // ...
    }
}

这种方式彻底避免了同步调用的锁问题，适合对实时性要求不高的场景。

关于TransactionSynchronizationManager无效的说明 #

你提到的TransactionSynchronizationManager是Spring框架的类，Java EE原生环境中并不存在。Java EE中对应的是javax.transaction.Synchronization，但它只能在当前事务的生命周期回调中执行操作，无法启动新事务。如果想用这种方式，需要在回调中触发异步操作（比如调用异步EJB方法），但复杂度高于前面的方案，不推荐优先使用。

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