Spring Batch多数据源事务管理异常问题咨询

我之前也遇到过几乎一模一样的问题——用两个Oracle数据源分别存Spring Batch元数据和业务数据，结果ItemWriter里的业务表操作总是时灵时不灵，要么提交了元数据但业务数据没写进去，要么反过来。折腾了好一阵，终于找到几个靠谱的方案，分享给你：

1. 正确配置ChainedTransactionManager（解决你之前的装配问题） #

ChainedTransactionManager其实是Spring Batch官方推荐的多数据源事务方案，但很多人栽在配置顺序和依赖注入上。核心思路是把两个数据源的事务管理器串成一个链，让整个块的操作（包括元数据更新和业务写入）都在同一个事务上下文里。

具体配置步骤（Java Config为例） #

首先，分别定义两个数据源对应的事务管理器，一定要用@Qualifier明确区分，避免Spring注入混淆：

@Bean("batchTransactionManager")
public PlatformTransactionManager batchTransactionManager(@Qualifier("batchDataSource") DataSource batchDataSource) {
    return new DataSourceTransactionManager(batchDataSource);
}

@Bean("businessTransactionManager")
public PlatformTransactionManager businessTransactionManager(@Qualifier("businessDataSource") DataSource businessDataSource) {
    return new DataSourceTransactionManager(businessDataSource);
}

然后创建链式事务管理器，注意顺序：把业务事务管理器放在前面，批处理的放在后面——这样提交时会先处理业务数据的事务，再处理元数据的，任何一步失败都会触发全链回滚：

@Bean
public ChainedTransactionManager chainedTransactionManager(
        @Qualifier("businessTransactionManager") PlatformTransactionManager businessTxManager,
        @Qualifier("batchTransactionManager") PlatformTransactionManager batchTxManager) {
    return new ChainedTransactionManager(businessTxManager, batchTxManager);
}

最后，在你的Step配置里指定这个链式事务管理器，替换默认的批处理事务管理器：

@Bean
public Step myBusinessStep(ItemReader<MyData> reader, ItemProcessor<MyData, MyData> processor, ItemWriter<MyData> writer) {
    return stepBuilderFactory.get("myBusinessStep")
            .<MyData, MyData>chunk(100)
            .reader(reader)
            .processor(processor)
            .writer(writer)
            .transactionManager(chainedTransactionManager()) // 关键：绑定链式事务管理器
            .build();
}

解决你遇到的装配问题 #

你之前说配置ChainedTransactionManager时遇到问题，大概率是这两个原因：

• 没有给事务管理器加@Qualifier，Spring不知道该注入哪个PlatformTransactionManager
• 链式事务管理器的依赖注入写错了，比如把参数类型搞混了
  按照上面的代码，用明确的Bean名称和@Qualifier，应该能解决装配问题。

2. 确保业务操作绑定到正确的数据源 #

光有事务管理器还不够，你得保证ItemWriter里的业务操作确实用的是业务数据源，而不是批处理的元数据数据源：

• 如果用JdbcTemplate，要为业务数据源单独配置一个：

  @Bean("businessJdbcTemplate")
  public JdbcTemplate businessJdbcTemplate(@Qualifier("businessDataSource") DataSource businessDataSource) {
      return new JdbcTemplate(businessDataSource);
  }
  

  然后在ItemWriter里注入这个businessJdbcTemplate，不要用默认的。
• 如果用Spring Data JPA，要为业务数据源单独配置EntityManagerFactory，并且让你的业务Repository绑定到这个工厂，避免和批处理的EntityManagerFactory混淆。

另外，不要在ItemWriter的方法上单独加@Transactional——步骤的块级事务已经覆盖了整个读-处理-写流程，单独加会导致嵌套事务，反而破坏一致性。

3. 备选方案：JTA分布式事务（如果Chained方案不满足） #

如果你的两个数据源是完全独立的Oracle实例，或者需要更严格的跨库事务保证，可以用JTA事务管理器（比如Atomikos、Bitronix），配合Oracle的XA数据源。

这种方案的核心是把两个数据源都配置成XA兼容的，然后用JTA事务管理器来管理全局事务。优点是真正的分布式事务，保证两个数据源要么都提交要么都回滚；缺点是配置复杂，性能开销比ChainedTransactionManager大，因为XA需要两阶段提交。

4. 验证事务一致性的小技巧 #

配置完后，一定要做异常测试：在ItemWriter里故意抛出RuntimeException，然后检查：

• 批处理元数据的STEP_EXECUTION状态是不是FAILED，而不是COMPLETED
• 业务数据库里有没有写入/更新的数据
  如果两者都符合预期（元数据回滚，业务数据也没写入），说明事务配置是对的。

总的来说，ChainedTransactionManager是最适合大多数场景的方案，只要配置正确，就能实现你要的可预测、健壮的事务管理。如果是跨不同数据库的极端场景，再考虑JTA。

内容的提问来源于stack exchange，提问作者Arpit S