|
此版本仍在开发中，尚不被认为是稳定的。对于最新的稳定版本，请使用 Spring Batch 文档 5.2.2！ |
配置Step用于重新启动
在“配置和运行作业”部分中，重新启动Job被讨论过。重启对步骤有很多影响，因此可能会
需要一些特定的配置。
设置起始限制
在许多情况下，您可能希望控制Step能
开始。例如，您可能需要配置特定的Step这样
仅运行一次，因为它会使某些资源失效，必须先手动修复这些资源才能修复
再次运行。这是在步骤级别上配置的，因为不同的步骤可能有
不同的要求。一个Step只能执行一次的可以作为
相同Job作为Step可以无限运行。
-
Java
-
XML
以下代码片段显示了 Java 中的启动限制配置示例：
@Bean
public Step step1(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
return new StepBuilder("step1", jobRepository)
.<String, String>chunk(10, transactionManager)
.reader(itemReader())
.writer(itemWriter())
.startLimit(1)
.build();
}以下代码片段显示了 XML 中的启动限制配置示例：
<step id="step1">
<tasklet start-limit="1">
<chunk reader="itemReader" writer="itemWriter" commit-interval="10"/>
</tasklet>
</step>前面示例中所示的步骤只能运行一次。尝试再次运行它
导致StartLimitExceededException被扔掉。请注意，默认值
start-limit 是Integer.MAX_VALUE.
重新启动已完成的Step
对于可重新启动的作业，可能有一个或多个步骤应始终
运行，无论他们第一次是否成功。一个例子可能
是验证步骤或Step在处理之前清理资源。在
重新启动的作业的正常处理，状态为COMPLETED（意思是
已成功完成），被跳过。设置allow-start-if-complete自true覆盖此步骤，以便该步骤始终运行。
-
Java
-
XML
以下代码片段显示了如何在 Java 中定义可重启的作业：
@Bean
public Step step1(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
return new StepBuilder("step1", jobRepository)
.<String, String>chunk(10, transactionManager)
.reader(itemReader())
.writer(itemWriter())
.allowStartIfComplete(true)
.build();
}以下代码片段演示了如何在 XML 中定义可重启的作业：
<step id="step1">
<tasklet allow-start-if-complete="true">
<chunk reader="itemReader" writer="itemWriter" commit-interval="10"/>
</tasklet>
</step>Step重启配置示例
-
Java
-
XML
以下 Java 示例演示如何配置作业以具有可以 重新 启动：
@Bean
public Job footballJob(JobRepository jobRepository, Step playerLoad, Step gameLoad, Step playerSummarization) {
return new JobBuilder("footballJob", jobRepository)
.start(playerLoad)
.next(gameLoad)
.next(playerSummarization)
.build();
}
@Bean
public Step playerLoad(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
return new StepBuilder("playerLoad", jobRepository)
.<String, String>chunk(10, transactionManager)
.reader(playerFileItemReader())
.writer(playerWriter())
.build();
}
@Bean
public Step gameLoad(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
return new StepBuilder("gameLoad", jobRepository)
.allowStartIfComplete(true)
.<String, String>chunk(10, transactionManager)
.reader(gameFileItemReader())
.writer(gameWriter())
.build();
}
@Bean
public Step playerSummarization(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
return new StepBuilder("playerSummarization", jobRepository)
.startLimit(2)
.<String, String>chunk(10, transactionManager)
.reader(playerSummarizationSource())
.writer(summaryWriter())
.build();
}以下 XML 示例演示如何将作业配置为具有可以 重新 启动：
<job id="footballJob" restartable="true">
<step id="playerload" next="gameLoad">
<tasklet>
<chunk reader="playerFileItemReader" writer="playerWriter"
commit-interval="10" />
</tasklet>
</step>
<step id="gameLoad" next="playerSummarization">
<tasklet allow-start-if-complete="true">
<chunk reader="gameFileItemReader" writer="gameWriter"
commit-interval="10"/>
</tasklet>
</step>
<step id="playerSummarization">
<tasklet start-limit="2">
<chunk reader="playerSummarizationSource" writer="summaryWriter"
commit-interval="10"/>
</tasklet>
</step>
</job>前面的示例配置适用于加载有关足球的信息的作业
游戏并总结它们。它包含三个步骤：playerLoad,gameLoad和playerSummarization.这playerLoadstep 从平面文件加载播放器信息，
而gameLoadstep 对游戏也做同样的事情。最后一步，playerSummarization，然后根据
提供游戏。假设由playerLoad必须仅加载
一次，但那个gameLoad可以加载在特定目录中找到的任何游戏，
在成功加载到数据库中后删除它们。结果，
这playerLoad步骤不包含其他配置。它可以启动任何数字
如果完成，则跳过次数。这gameLoad但是，需要运行步骤
每次，以防自上次运行以来添加了额外的文件。它有allow-start-if-complete设置为true始终启动。（假设
游戏加载到的数据库表上有一个进程指示器，以确保
新游戏可以通过摘要步骤正确找到）。汇总步骤
这是作业中最重要的，配置为起始限制为 2。这
很有用，因为如果该步骤持续失败，则新的退出代码将返回给
控制作业执行的运算符，并且在手动之前无法重新启动
干预已经发生。
此作业提供了本文档的示例，与footballJob在示例项目中找到。 |
本节的其余部分描述了footballJob例。
运行 1：
-
playerLoad运行并成功完成，将 400 名玩家添加到PLAYERS桌子。 -
gameLoad运行并处理相当于 11 个文件的游戏数据，加载其内容 进入GAMES桌子。 -
playerSummarization开始处理，5 分钟后失败。
运行 2：
-
playerLoad不运行，因为它已经成功完成，并且allow-start-if-complete是false（默认值）。 -
gameLoad再次运行并处理另外 2 个文件，将其内容加载到GAMES表（带有一个过程指示器，表明它们尚未 处理）。 -
playerSummarization开始处理所有剩余的游戏数据（使用 进程指示器），30 分钟后再次失败。
运行 3：
-
playerLoad不运行，因为它已经成功完成，并且allow-start-if-complete是false（默认值）。 -
gameLoad再次运行并处理另外 2 个文件，将其内容加载到GAMES表（带有一个过程指示器，表明它们尚未 处理）。 -
playerSummarization未启动，作业会立即终止，因为这是 第三次执行playerSummarization，其限制仅为 2。要么是限制 必须提高或Job必须作为新的JobInstance.