Spring事务监听与传播行为疑问：AFTER_COMMIT阶段报错及REQUIRES_NEW生效原因咨询

兄弟，我来帮你把这个问题掰明白，核心原因其实和Spring事务监听的执行时机、传播行为的规则，还有事务上下文的状态都有关系：

先搞懂AFTER_COMMIT监听器的执行时机 #

你用的@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)，这个监听器是在触发它的原事务完全提交之后才会执行的。也就是说，当你的OffsettingJpaRepository.save()或者saveAndFlush()方法完成，对应的事务已经彻底提交、线程里的事务上下文已经被Spring清理干净了，这时候监听器才开始跑，当前线程根本没有活跃的事务。

为什么用REQUIRED会报错？ #

REQUIRED的规则是：如果当前有活跃事务就加入，没有就新建一个。理论上这里应该新建事务，但问题出在AFTER_COMMIT这个特殊阶段的执行环境：

• 原事务提交后，Spring的事务同步管理器可能还残留着一些原事务的状态标记（比如“事务已完成”的标识），这会干扰REQUIRED的逻辑——它可能误以为当前不需要新建事务，或者事务切面没能正确触发，导致你的createMessageToRo方法实际上没有被事务包裹。
• 当你执行offsettingDao.save(offsettingEntity)这类需要事务支持的JPA操作时，因为没有事务上下文，自然就抛出了no transaction is in progress的错误。

为什么REQUIRES_NEW就没问题？ #

REQUIRES_NEW的规则是强制创建一个全新的独立事务，不管当前有没有活跃事务（如果有就先挂起）。

• 这个传播行为完全无视当前线程里残留的原事务状态，直接启动一个干净的新事务，所以你的createMessageToRo方法会被正确包裹在事务里，所有需要事务的数据库操作都能正常执行，自然不会报错。

结合你的代码再补充一句 #

你的postSave监听器本身没加@Transactional，而是调用了OffsettingOutboxService的方法，事务注解的生效依赖Spring代理。REQUIRES_NEW因为强制新建事务的特性，能确保事务切面100%触发；而REQUIRED在AFTER_COMMIT的特殊环境下，就容易因为上下文残留的状态“卡壳”，导致事务没被正确创建。

最后给个小建议：在AFTER_COMMIT阶段执行数据库操作时，优先用REQUIRES_NEW，毕竟这个阶段本身就是原事务结束后的无事务环境，REQUIRES_NEW能给你一个可靠的独立事务，避免各种奇怪的问题。

内容来源于stack exchange