Spring Integration触发Spring Batch时出现事务错误的解决方案咨询

你遇到的这个错误核心原因确实是外部事务上下文与Spring Batch的事务管理机制冲突——Spring Batch的JobRepository默认会校验当前是否存在外部事务，因为它需要完全掌控作业执行的全生命周期事务（比如步骤提交、失败回滚等），而你给轮询器配置的transactional(new PseudoTransactionManager())恰好给作业启动流程套了一层外部事务，触发了这个校验逻辑。

既然你不想修改JobRepository的validateTransactionState配置，我们可以从Spring Integration的配置入手，从根源上消除外部事务的影响，同时保留你需要的“根据作业结果移动文件”的能力：

解决方案步骤 #

1. 移除轮询器的事务绑定 #

首先删掉轮询器配置里的transactional部分，这是引入外部事务的源头：

return IntegrationFlows.from(fileReadingMessageSource, c -> c.poller(Pollers.fixedDelay(period)
    .taskExecutor(taskExecutor)
    .maxMessagesPerPoll(maxMessagesPerPoll)
    // 移除这行：.transactional(new PseudoTransactionManager())
    .transactionSynchronizationFactory(transactionSynchronizationFactory())))

2. 封装作业启动逻辑，强制无事务执行 #

创建一个专门的消息处理器，把作业启动和文件移动逻辑绑定，并用事务传播属性强制在无事务上下文执行作业：

@Component
public class JobLaunchingFileHandler {

    private final JobLauncher jobLauncher;
    private final FileProcessingJob importJob; // 替换成你的Job类
    private final FileMovingMessageHandler successFileHandler;
    private final FileMovingMessageHandler errorFileHandler;

    // 构造注入所有依赖
    public JobLaunchingFileHandler(JobLauncher jobLauncher, FileProcessingJob importJob,
                                   FileMovingMessageHandler successFileHandler,
                                   FileMovingMessageHandler errorFileHandler) {
        this.jobLauncher = jobLauncher;
        this.importJob = importJob;
        this.successFileHandler = successFileHandler;
        this.errorFileHandler = errorFileHandler;
    }

    // 强制此方法在无事务环境下执行，彻底脱离外部事务
    @Transactional(propagation = Propagation.NOT_SUPPORTED)
    public void launchJobAndHandleFile(File file) throws JobExecutionException {
        // 构建作业参数，确保每次启动都是唯一作业实例
        JobParameters jobParameters = new JobParametersBuilder()
                .addString("filePath", file.getAbsolutePath())
                .addLong("timestamp", System.currentTimeMillis())
                .toJobParameters();

        // 启动作业并获取执行结果
        JobExecution jobExecution = jobLauncher.run(importJob, jobParameters);

        // 根据作业状态移动文件
        if (BatchStatus.COMPLETED.equals(jobExecution.getStatus())) {
            successFileHandler.handleMessage(new GenericMessage<>(file));
        } else {
            errorFileHandler.handleMessage(new GenericMessage<>(file));
        }
    }
}

3. 修改IntegrationFlow，调用自定义处理器 #

把原来的作业启动逻辑替换成调用这个自定义处理器：

return IntegrationFlows.from(fileReadingMessageSource, c -> c.poller(Pollers.fixedDelay(period)
    .taskExecutor(taskExecutor)
    .maxMessagesPerPoll(maxMessagesPerPoll)))
    .handle(jobLaunchingFileHandler, "launchJobAndHandleFile")
    .get();

为什么之前的异步JobLauncher没用？ #

你尝试的异步JobLauncher只是把作业执行放到了新线程，但如果启动作业的主线程仍处于外部事务上下文，新线程可能会继承这个事务（取决于事务管理器配置），或者作业启动的触发点依然在外部事务里，并没有真正脱离事务环境。而Propagation.NOT_SUPPORTED是强制挂起当前事务（如果存在），确保作业在完全无事务的环境下启动，从根源上解决了JobRepository的校验问题。

额外说明 #

原来的TransactionSynchronizationFactory依赖事务上下文来触发文件移动，现在我们通过手动判断作业执行结果来实现同样的逻辑，完全不需要依赖外部事务，既保留了业务需求，又解决了冲突问题。

内容的提问来源于stack exchange，提问作者Luciano Fiandesio