Spring批处理事务管理是如何工作的？

Question

我想了解Spring Batch是如何进行事务管理的。这不是一个技术问题，而是一个概念性的问题：Spring Batch使用什么方法？这种方法的后果是什么？

让我试着澄清一下这个问题。例如，在TaskletStep中，我看到步骤执行通常如下所示：

1. 准备步骤元数据的几个JobRepository事务
2. 每一块要处理的业务事务
3. 更多JobRepository事务，用区块处理的结果更新步骤元数据

这似乎是有道理的。但是2到3之间的失败呢？这意味着业务事务已提交，但Spring Batch无法在其内部元数据中记录这一事实。因此，重新启动将再次重新处理相同的项目，即使它们已经提交。对吗？

我正在寻找对这些细节的解释以及Spring Batch中做出的设计决策的后果。这是否记录在某处？Spring Batch参考指南对此的详细信息很少。它只是从应用程序开发人员的角度解释事情。

Answer 1

Spring Batch中有两种基本类型的步骤，Tasklet步骤和基于块的步骤。每个都有自己的事务详细信息。让我们看看每个：

基于Tasklet的步骤
当开发人员实现他们自己的tasklet时，事务性非常简单。对Tasklet#执行方法的每次调用都在事务中执行。您是正确的，因为在执行步骤的逻辑之前和之后都有更新。从技术上讲，它们没有包装在事务中，因为我们不想为作业存储库更新支持回滚。

基于块的步骤
当开发人员使用基于块的步骤时，由于增加了跳过/重试的功能，因此会涉及更多的复杂性。但是，从简单的层面来看，每个块都是在事务中处理的。出于前面提到的相同原因，您在基于块的步骤之前和之后仍然有相同的更新，这些更新是非事务性的。

在您的问题中，“如果”场景中，您询问如果业务逻辑完成，但由于某种原因，对作业存储库的更新失败，会发生什么。重新启动时是否会重新处理以前更新的项目。和大多数事情一样，这要看情况而定。如果您使用的是有状态的读写器，比如FlatFileItemReader，则每次提交业务事务时，作业存储库都会更新为已处理内容的当前状态（在同一事务中）。因此，在这种情况下，重新启动作业将恢复其停止的位置。。。在这种情况下，在结束，并没有额外的记录处理。

如果您没有使用有状态的读写器或已关闭“保存状态”，则需要谨慎一点，最终可能会出现您描述的情况。框架中的默认行为是保存状态，以便保留可重启性。