Spring默认DataSourceTransactionManager不感知Oracle XID，多数据源事务各自独立；必须用JtaTransactionManager+XADataSource（如UCP）并显式指定事务管理器，且Oracle需启用分布式事务支持。
Oracle XID 在 Spring 中无法跨数据源自动对齐
spring 默认的 datasourcetransactionmanager 不感知 oracle 的全局事务 id（xid），哪怕两个 oracle 数据源都配置了 xadatasource，@transactional 也只会为每个数据源单独开启本地事务。日志里看到 committing transaction on datasource 'ds-order' 和 committing transaction on datasource 'ds-audit' 是两套独立的 xid，v$transaction 查出来的 xidusn/xidslot/xidsqn 完全不同——这不是“回滚没生效”，而是根本没进两阶段提交流程。
必须用 JTA + XADataSource 才能生成可协调的 Oracle XID
Oracle 要参与分布式事务，JDBC 层必须走 javax.sql.XADataSource，且 Spring 必须用 JtaTransactionManager（或 JotmJtaTransactionManager、AtomikosJtaTransactionManager）作为事务管理器。关键点：
-
XADataSource实现类不能是OracleDriver自带的oracle.jdbc.xa.client.OracleXADataSource（已废弃），得用oracle.ucp.jdbc.PoolXADataSourceImpl或官方推荐的oracle.jdbc.xa.client.OracleXADataSource的替代品（如 Oracle 12c+ 推荐用 UCP） - Spring Boot 2.3+ 需显式排除自动配置：
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration -
JtaTransactionManager必须通过@Primary标记，并在@Transactional中显式指定：@Transactional(transactionManager = "jtaTransactionManager") - Oracle 侧需确认数据库启用了分布式事务支持：
SELECT * FROM v$option WHERE parameter = 'Distributed Transaction Processing';返回TRUE
XA 模式下 Oracle 分支注册失败的典型现象
即使配对了 XADataSource 和 JtaTransactionManager，仍可能遇到分支注册失败，错误日志常含：ORA-02049: timeout: distributed transaction waiting for lock 或 XAER_RMERR。原因多为：
- Oracle 数据库未配置
distributed_lock_timeout参数（默认 60 秒），长事务容易超时；可在初始化脚本中执行：ALTER SYSTEM SET distributed_lock_timeout=120 SCOPE=BOTH; - 同一 JVM 内多个
XADataSource实例共享了相同xaDataSourceName，导致 Oracle 服务端混淆分支归属；每个数据源的setXaDataSourceName("ds-order-xa")必须唯一 - 应用未启用 JTA 全局事务上下文传播，比如用
RestTemplate调用下游服务时，XID 不会自动透传——这和 Seata 的@GlobalTransactional不同，JTA 的 XID 仅限当前 JVM 内部传播
XA 事务在 Oracle RAC 环境下的真实约束
很多人误以为只要用了 XA 就能在 RAC 多实例间保证一致性，其实不然。Oracle RAC 中，不同节点上的实例拥有独立的事务管理器（TM），XA 协调器（如 Atomikos）只能保证「单个实例内」的分支事务被正确 prepare/commit，但无法强制跨节点的锁等待或 SCN 同步。实际部署时：
- 所有参与同一 XA 全局事务的 SQL 必须路由到同一个 RAC 实例（通过 service name + preferred instance 绑定）
- 避免在
SELECT ... FOR UPDATE后跨库更新，否则极易触发ORA-02049；应改用乐观锁或业务层重试 -
undo_tablespace必须在所有 RAC 节点上可用且大小充足，prepare 阶段生成的 undo record 若被覆盖，commit 阶段将失败
XA 是强一致方案，但代价是阻塞、超时敏感、运维复杂。真正需要跨 Oracle 数据库的分布式事务，优先评估是否能下沉为最终一致性（如发 MQ + 补偿），而非硬上 XA。
