有没有办法重新定义数据库"事务性的"；春季批量作业的边界？
上下文：
我们有一个简单的支付处理作业，它读取x个支付记录，处理并标记数据库中的记录为已处理。目前，作者执行REST API调用(对支付网关(，处理API响应，并将记录标记为已处理。我们正在做一种面向区块的方法，这样在整个区块完成之前，更新不会刷新到数据库中。由于基本上整个读/写都在一个事务中，我们开始看到过多的数据库锁定和争用。例如，如果API需要很长时间(比如30秒(来响应，那么整个应用程序就会开始受到影响。
我们显然可以将API调用的超时时间减少到一个较小的值。。但这仍然不能解决表可能被锁定超过所需持续时间的问题。理想情况下，我们希望尽可能短时间地保存数据库事务。我们的想法是，如果；肉；关于可以在数据库事务之外完成的工作，我们可以绕过这个问题。因此，如果API调用发生在数据库事务之外。。我们可以让它多花几秒钟的时间来接受响应，而不会导致/增加长的锁定持续时间。
这是正确的方法吗？如果没有，建议采用什么方法来处理这个"问题"；简单的"；春季批量时尚的工作？是否有其他更适合该任务的批处理工具？(如果弹簧批次不是正确的选择(。
如果需要，可以提供更多上下文。
我没有你所有问题的确切答案，但我会尝试给出一些指导方针。
由于基本上整个读/写都在一个事务中，我们开始看到过多的数据库锁定和争用。例如，如果API需要很长时间(比如30秒(来响应，那么整个应用程序就会开始受到影响。
自诞生以来，术语"批处理"或"处理"中的数据；批次"；基于将一批记录视为一个单元的想法：要么处理所有记录(无论"过程"一词的意思是什么(，要么不处理任何记录。这个"；要么全有要么全无"；语义正是SpringBatch在其面向块的处理模型中实现的。实现这样一个(强大的(财产需要权衡。在您的情况下，您需要在一致性和响应性之间进行权衡。
我们可以明显地将API调用的超时减少到一个较小的值。。但这仍然不能解决表可能被锁定超过所需持续时间的问题。
区块大小是对事务行为影响最大的参数。您可以做的是尝试减少单个事务中要处理的记录数量，并查看结果。没有最佳价值，这是一个经验过程。这还将取决于您在处理区块期间调用的API的响应性。
我们的想法是，如果；肉；关于可以在数据库事务之外完成的工作，我们可以绕过这个问题。因此，如果API调用发生在数据库事务之外。。我们可以让它多花几秒钟的时间来接受响应，而不会导致/增加长的锁定持续时间。
避免在实时系统上进行此类更新的一种常见技术是针对另一个数据存储卸载处理，然后在单个事务中复制更新。其想法是用给定的批处理id标记记录，并将这些记录复制到不同的数据存储区(甚至是同一数据存储区内的临时表(，批处理过程可以在不影响实时数据存储的情况下使用该数据存储区。一旦处理完成(可以并行进行以提高性能(，就可以在单个事务中将记录标记为在活动系统中处理(这通常非常快，并且可以基于批id来识别要更新的记录(。