XADataSource在微服务中基本不可用，因其依赖的两阶段提交（2PC）与微服务的网络不可靠、服务独立部署、超时策略差异等核心约束根本冲突，易导致悬挂事务、资源锁死及跨服务事务上下文无法传递等问题。
XADataSource 为什么在微服务里基本没法用
微服务架构下，xadatasource 的两阶段提交（2pc）几乎不可行——不是语法不会写，而是它和微服务的核心约束根本冲突。2pc 要求全局事务协调器（如 transactionmanager）长期持有数据库连接、锁住资源直到所有分支确认，而微服务之间网络不可靠、服务独立部署、超时策略各异，一个分支卡住就会拖垮整个事务链。
常见错误现象：XAException: XAER_RMFAIL 或 XAException: XAER_NOTA 频发；服务重启后出现悬挂事务（in-doubt transaction），数据库里 SELECT * FROM DBA_2PC_PENDING 查出一堆未决记录；Spring Boot 启动时报 NoUniqueBeanDefinitionException 找不到唯一的 PlatformTransactionManager。
- 每个微服务通常只配一个数据源，但
XADataSource要求每个参与方都注册到同一个 TM，这需要跨进程共享事务上下文，JDBC 层做不到 -
javax.sql.XADataSource是 JVM 进程内协议，无法跨服务序列化传递Xid和分支日志 - 主流云数据库（如阿里云 PolarDB、AWS Aurora）已明确不支持外部 XA 协调，仅保留内部 XA 用于主从一致性
Spring Boot + Atomikos 配置 XADataSource 的典型失败点
即使你坚持在单体或类单体场景中尝试 XADataSource，Atomikos 是最常选的 JTA 实现，但它的默认行为和 Spring Boot 自动配置存在几处隐蔽冲突。
使用场景：本地多数据源（比如 MySQL + PostgreSQL）需强一致写入，且不接受最终一致性。
- 必须手动禁用 Spring Boot 的
JtaAutoConfiguration，否则它会试图用 Bitronix 或 Narayana，和 Atomikos 冲突 -
AtomikosDataSourceBean的uniqueResourceName必须全局唯一，相同名字在多个实例中会导致 XA 分支混用，报XAException: XAER_DUPID - MySQL 驱动需显式启用 XA：
jdbc:mysql://...?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=UTC&rewriteBatchedStatements=true后面加&allowMultiQueries=true不够，还得确认 MySQL 服务端innodb_support_xa=ON（8.0.23+ 已默认关闭，需手动开） - PostgreSQL 要用
org.postgresql.xa.PGXADataSource，不能用普通PGSimpleDataSource，否则运行时报java.lang.ClassCastException: ... cannot be cast to javax.sql.XADataSource
替代方案：什么时候该放弃 XA，改用 Saga 或本地消息表
只要服务间存在 HTTP/gRPC 调用、数据库不在同一物理集群、或任何一方是第三方系统（如支付网关），就该立刻放弃 XADataSource。这时候真正可落地的是补偿型事务模型。
性能与兼容性影响：XA 事务平均耗时比本地事务高 3–5 倍，且无法利用连接池的 autoCommit=false 批量优化；而 Saga 模式下每个步骤都是独立本地事务，吞吐量不降反升。
- 本地消息表适用场景：你控制所有服务代码，能改数据库 schema，在业务库中加一张
outbox表，用定时任务或 CDC 同步事件 - Saga 编排模式（Orchestration）适合复杂流程，但需引入
Service Orchestrator服务，状态机逻辑容易散落在各处；Choreography 模式靠事件驱动，更松耦合，但调试困难 - 不要试图在 Spring Cloud Stream 上直接套 XA——
KafkaBinder不实现XAResource，beginTransaction()调用会直接抛UnsupportedOperationException
如果非得测通 XA，最小可行验证步骤
只是为了验证环境是否支持 XA（比如给 DBA 提需求、或压测老系统），别写业务逻辑，只跑通最简路径。
实操建议：用 H2 内存数据库做快速验证，它支持 XA 且无需额外配置，避免被 MySQL/Oracle 权限或参数卡住。
- 依赖只留
atomikos-jta和h2，去掉所有 Spring Cloud 相关 starter - 配置两个
AtomikosDataSourceBean，uniqueResourceName分别设为h2-1和h2-2，URL 加;DB_CLOSE_DELAY=-1防止连接被 H2 自动关掉 - 事务方法上用
@Transactional，但必须指定transactionManager = "jtaTransactionManager"，不能依赖默认 - 触发异常时观察日志是否出现
committing branch/rolling back branch，而不是只有一方回滚
真正在生产微服务里配通 XA 的团队，99% 后来都重构掉了——不是技术没跑通，是运维成本、监控盲区和故障恢复时间远超预期。分布式事务最难的从来不是怎么写，而是怎么知道它没写对。
