当副作用遇上事务传播：一个时序问题的两次误判

Tue, 22 Sep 2026 00:00:00 +0000

在基于 Spring 事务管理的系统中，业务副作用（如消息发送）与事务提交之间的时序一致性是一个容易被忽视的问题。当业务逻辑涉及嵌套方法调用，且内外层方法共享同一事务上下文时，“业务逻辑完成"与"事务提交"之间存在语义上的不等价性。

本文通过两次生产故障的分析，揭示事务传播语义和事务同步回调生命周期中两个易被误判的时序节点。两次故障的共同特征是：出问题的代码本身逻辑正确，但被放入了预期之外的事务上下文。

注：本文中的代码均为伪代码，用于说明问题结构，不代表实际生产代码。

问题背景

系统中存在一个通用的状态机处理组件，负责状态流转并在流转完成后发送消息通知下游。该组件独立运行时工作正常——方法自身声明了 @Transactional，状态变更提交后再发消息，时序无误。

问题出现在该组件被其他业务代码调用时：外层调用方也持有事务，导致状态机组件不再是事务的发起者，其对提交时机的假设随之失效。

第一次故障：外层事务改变了提交边界

现象

状态机组件在状态流转完成后直接发送消息，消费者反查数据库，发现数据不存在。

状态机组件的代码：

@Transactional
public void transition(Long orderId, State targetState) {
 stateMachineRepository.updateState(orderId, targetState);
 messageSender.send(orderId); // ← 状态流转完成，发送消息
}

该组件被某个业务方法调用，而该业务方法自身也声明了事务：

@Transactional
public void createOrder(OrderRequest request) {
 orderRepository.save(new Order(request));
 stateMachineService.transition(request.getOrderId(), State.CREATED);
 // 后续逻辑...
}

调用链如下：

createOrder() ← 事务发起者（非状态机组件）
 └─ orderRepository.save()
 └─ transition() ← REQUIRED, 加入外层事务
 └─ stateMachineRepository.updateState() ← 写入状态变更
 └─ messageSender.send() ← 消息发出，但事务尚未提交
 └─ 后续逻辑...
事务提交 → Connection.commit() ← 真正的提交在这里

分析

transition() 声明了 @Transactional，传播行为为默认的 REQUIRED。当 transition() 独立调用时，它自身即为事务发起者，方法返回时触发提交，消息发送时序正确。但当 createOrder() 在外层开启了事务时，transition() 加入的是外层事务，两者映射到同一个物理事务，内层方法不具备独立的提交点。

Spring on arjenzhou

当副作用遇上事务传播：一个时序问题的两次误判

问题背景

第一次故障：外层事务改变了提交边界

现象

分析