具有可重试和可跳过异常的jsr 352批处理可能会多次处理项目

cor*_*rnz 5 java java-ee jsr352 jbatch jberet

我有一个用JSR-352(在wildfly上使用jberet)实现的批处理。

我有一个项目计数为15的块,并java.lang.Exception配置为可重试和可跳过的异常。

当有很多例外时,大多数项目将被多次处理。在这种极端情况下,所有项目都会在编写器中引发异常:

  • 读取前15个项目
  • 第一项发生例外
  • 块将回滚并配置为item-count = 1
  • 第一项被阅读
  • 再次发生异常,项目被跳过
  • 继续进行其他14个项目,每个项目可能会发生异常,每个项目都将被跳过
  • 在前15个项目之后,该块以item-count = 15返回
  • 读取项目16-30
  • 再次发生异常
  • 阅读器回滚到最新的检查点

此时,由于没有成功的已处理项目,因此仍然没有检查点。因此,读者再次从第一项开始。所有30个项目的item-count = 1等。

如果存在许多此类失败,则批次将一次又一次地处理所有项目。

我认为也需要为跳过的项目设置检查点,因为跳过的项目不应该再次处理。

我认为这是规范中的错误,所以我已经在那打开了一个问题:https : //github.com/WASdev/standards.jsr352.batch-spec/issues/15 还是我错了,并且误解了实现?

在Spring Batch中如何实现?

Sco*_*urz 2

我认为规范足够清楚,这表明这可能是 JBeret 错误(假设这不是应用程序问题)。

在规范(此处为非官方版本)中,以下部分:

8.2.1.4.3 重试并跳过相同的异常

表示在回滚重试期间,一次处理一个项目(在一项块中),并且在重试期间跳过优先。

因此,如果重试期间发生可跳过的异常,则只会跳过该项目,并且应保留更新的检查点。这就是我所从事的 JSR 352 实现WebSphere Liberty Batch 的工作原理。

因此,我建议生成一个重新创建项目,并打开一个 JBeret 问题(如果它看起来仍然像这样)。目前,我没有看到规格问题。

  • 确实,您不会看到任何有关在重试期间跳过需要更新检查点的信息。实际上,规范并没有明确说明在任何跳过之后都会采取新的检查点。假定“明显”的是“跳过”意味着不回滚、重试或执行失败。由于检查点是在正常块的末尾获取的,因此,应该在涉及跳过项目的块的末尾获取检查点。这也适用于回滚后重试中使用的特殊单项块。所以,我并不是说规范再清楚不过了。只是重构推理。 (2认同)