Oracle多数据源时@Transactional不生效的典型表现是事务未回滚或仅对单数据源起作用；根本原因是默认只配置一个PlatformTransactionManager，需为每个DataSource显式声明对应事务管理器并用限定符指定。

Oracle 多数据源时 @Transactional 不生效的典型表现

事务没回滚，RuntimeException 抛出后数据仍写入数据库；或事务看似“成功”，但实际只对一个数据源起作用。根本原因不是 Spring 的注解失效，而是 @Transactional 默认绑定到当前线程绑定的 DataSource 对应的 PlatformTransactionManager —— 而多数据源场景下，你很可能只配置了一个 PlatformTransactionManager，却在 Service 层混用了多个 JdbcTemplate 或 EntityManager。

必须为每个 Oracle 数据源显式声明对应的 PlatformTransactionManager

Spring 不会自动为每个 DataSource 创建事务管理器。如果你只保留了默认的 transactionManager Bean（比如叫 platformTransactionManager），那所有 @Transactional 都只会作用于它所管理的那个数据源。

实操建议：

• 为每个 Oracle 数据源定义独立的 DataSource Bean（如 primaryDataSource、secondaryDataSource）
• 为每个 DataSource 显式声明对应的 PlatformTransactionManager Bean（如 primaryTransactionManager、secondaryTransactionManager），构造时传入对应 DataSource
• 在需要事务的方法上用 @Transactional("primaryTransactionManager") 或 @Transactional("secondaryTransactionManager") 明确指定
• 切勿依赖 @EnableTransactionManagement 的“默认行为”——它只认名为 transactionManager 的 Bean

跨数据源事务（XA）不是默认选项，且 Oracle XA 配置极易出错

如果业务逻辑确实要同时操作两个 Oracle 数据库并保证原子性（比如 A 库扣库存 + B 库记日志），那就不是单个 @Transactional 能解决的，必须走 JTA/XA。但 Oracle 的 XA 支持对驱动版本、数据库配置、连接池（如 HikariCP 不支持 XA，得换 Atomikos 或 Bitronix）都有强约束。

常见错误现象：

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

• 抛出 javax.transaction.xa.XAException: The method 'xa_start' has failed with errorCode '-3' —— 通常是数据库未启用 XA 或用户缺少 SELECT ON SYS.XA_TRANSATIONS 权限
• 事务管理器初始化失败，日志里出现 No suitable driver found for jdbc:oracle:thin:@... —— XA 数据源要用 oracle.jdbc.xa.client.OracleXADataSource，不是普通 OracleDataSource
• 即使配置成功，性能下降明显，且无法与 Spring Boot 的自动配置共存，必须手动接管全部事务基础设施

最容易被忽略的坑：@Transactional 方法调用发生在同一个类内

哪怕事务管理器配置完全正确，如果 @Transactional 方法是被本类另一个非事务方法直接调用（比如 service.doA() 内部调用 this.doB()），事务依然不会生效 —— 因为 Spring AOP 代理只对**外部 Bean 调用**生效。

验证方式很简单：在 @Transactional 方法入口加一行 log.info("tx status: {}", TransactionSynchronizationManager.isActualTransactionActive());，运行看是否为 true。

修复路径只有两条：

• 把调用拆到另一个 @Service 类中（推荐）
• 通过 ApplicationContext 手动获取代理对象调用（不推荐，侵入性强）

这个坑和多数据源无关，但在复杂 Service 分层中极难排查，尤其当开发人员误以为“只要加了注解就一定有事务”。