ActiveMQ非XA数据源适配XA事务：配置正确性及运行原因咨询

一、是否必须更换为XA数据源？ #

没错，你必须把Broker的JdbcPersistenceAdapter切换为XA版本的数据源，这是保证你要的端到端Exactly-Once投递语义的必要条件。

为啥这么说？你的应用层已经基于Bitronix做了XA事务管理，涉及多数据源（部分XA、部分非XA）和JMS消息收发——这意味着应用侧的所有操作都在全局事务的协调下。但如果Broker的消息持久化用的是非XA数据源，那么Broker对消息状态的修改（比如标记消息为已消费、写入待投递队列）就完全脱离了这个全局事务的控制。这就像两个独立的事务在各自跑，看似结果一致，但本质上埋下了一致性爆炸的隐患。

二、为什么当前配置看起来一切正常？ #

你现在没遇到问题，主要是这几个原因：

1. 没触发极端故障场景 #

日常测试中，系统通常都是平稳运行的：应用提交事务时，Broker刚好顺利完成了消息状态的持久化；应用回滚时，Broker也刚好没把消息标记为已消费。但一旦碰到故障——比如应用提交XA事务成功后，Broker突然宕机（还没来得及更新消息状态），或者Broker的数据库连接中断导致消息状态写入失败——就会出现：应用侧已经完成了数据库操作和后续消息发送，但Broker认为消息还没被消费，会重新投递，直接破坏Exactly-Once语义。

2. 临时的机制巧合掩盖了问题 #

你提到消息重投递由Broker处理，当前应用侧XA事务回滚时，Bitronix会通知JMS资源回滚，而Broker的非XA数据源可能刚好在这个场景下，消息状态没有被持久化（比如Broker还没执行写操作就收到了回滚信号）。这种巧合让你觉得事务是一致的，但这完全不可靠——Broker的非XA操作不受Bitronix的全局事务协调，哪天时序变了，就会出现不一致。

3. 非XA资源的“模拟XA”带来的假象 #

Bitronix这类事务管理器对非XA资源有个叫**Last Resource Commit Optimization（LRCO）**的妥协方案，会尝试把非XA资源的操作纳入全局事务的最后一步。但Broker的JdbcPersistenceAdapter是独立于应用的组件，它的操作根本不在Bitronix的协调范围内——所以这只是你看起来事务一致，实际上Broker的消息状态变更和应用的XA事务是完全独立的两个操作，只是多数时候结果碰巧一致而已。

最后给个明确建议 #

别依赖当前的“正常表现”，赶紧把Broker的JdbcPersistenceAdapter换成XA数据源。只有让Broker的消息持久化操作也被纳入全局XA事务的协调中，才能真正保证：应用侧的数据库操作、JMS消息收发，和Broker的消息状态变更，要么一起成功，要么一起回滚，实现真正的端到端Exactly-Once投递。

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