Spring批量事务管理是如何工作的？ [英] How does Spring Batch transaction management work?
问题描述
我想了解Spring Batch是如何进行事务管理的。这不是一个技术问题，而更多的是一个概念性问题：Spring Batch使用什么方法，该方法的后果是什么？
让我试着澄清一下这个问题。例如，查看TaskletStep，我看到通常步骤执行如下所示：
- 准备步骤元数据的几个作业存储库事务
- 要处理的每个区块的业务事务
- 更多作业存储库事务使用区块处理结果更新步骤元数据
这似乎是有道理的。但是如果在2到3点之间出现故障呢？这意味着业务事务已经提交，但是Spring Batch无法在其内部元数据中记录这一事实。因此，重新启动将再次重新处理相同的项目，即使它们已经提交。对吗？
我正在寻找这些细节的解释，以及Spring Batch中做出的设计决策的后果。这在什么地方有记录吗？Spring Batch参考指南在这方面的细节很少。它只是从应用程序开发人员的角度解释问题。
推荐答案
Spring Batch中有两种基本类型的步骤，即微线程步骤和基于块的步骤。每个都有自己的交易明细。让我们来看看每一个：
基于Tasklet的步骤
当开发人员实现他们自己的tasklet时，事务性非常简单。对Tasklet#execute方法的每个调用都在事务内执行。您是正确的，因为在执行步骤的逻辑之前和之后都有更新。从技术上讲，它们没有包装在事务中，因为回滚不是我们希望作业存储库更新支持的东西。
基于块的步骤
当开发人员使用基于块的步骤时，由于添加了跳过/重试功能，因此涉及的复杂性会稍高一些。但是，从简单的角度来看，每个块都是在一个事务中处理的。由于前面提到的相同原因，您在基于区块的步骤之前和之后仍具有相同的非事务性更新。
假设方案
在您的问题中，您询问如果业务逻辑完成，但是作业存储库的更新由于某种原因而失败，将会发生什么情况。是否在重新启动时重新处理先前更新的项目。就像在大多数事情中一样，这要视情况而定。如果您使用像FlatFileItemReader这样的有状态读取器/写入器，则每次提交业务事务时，作业存储库都会使用(同一事务中)已处理内容的当前状态进行更新。因此，在这种情况下，作业的重新启动将从它停止的地方开始.在这种情况下，在结束时，不会处理任何其他记录。
如果您没有使用有状态的读取器/写入器，或者关闭了保存状态，那么这就有点让购买者当心了，您可能会出现您所描述的情况。框架中的默认行为是保存状态，以便保留可重启性。
这篇关于Spring批量事务管理是如何工作的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
