Java 批量事务控制

Question

我有一些用于与 bean 管理的事务一起运行的代码（我的代码将处理何时启动或提交事务）。此代码已迁移到容器管理的事务，并最终在 Java Batch 中使用（Wildfly 中的 JSR-352）。

现在我们处理的数据量不断增长，我们看到了与交易相关的问题。在各种情况下，即使查询失败，异常也表明事务被标记为仅回滚。所以我认为之前的迁移过程中一定发生了一些错误。

我仍然想使用容器管理的事务，但是......

• 如何在批处理中正确使用 CDI 以便它接收 EntityManager？我是使用 @PersistenceContext、@PersistenceUnit 或 @Inject 注释，还是组合使用？
• 如何利用合理的CDI范围？查看 https://github.com/jberet/jberet-user-guide/blob/master/custom_cdi_scopes/README.md 发现存在三个作用域：Job、Step 和 Partition。由于我的批处理运行时间太长，我可能需要分区范围，但是批处理如何控制分区？
• 我了解到读取器/处理器/写入器模式控制记录块数量的事务 ootb。该模式是否适用于读取记录、处理记录然后立即更新或删除记录的代码？

Answer 1

同时我发现了这个问题，与我发布一个模糊的问题类似，我现在可以看到我的问题的答案并不容易得出。

我的代码过去在没有容器的情况下运行，所以显然它自己管理事务。后来添加了一个容器，最终我开始编写使用容器管理事务的代码。但只有一个持久性单元，并且它被配置为容器管理的事务。在数据集增长之前，这在很长一段时间内似乎都不是问题。

我的解决方案是拥有两个持久性单元 - 一个有容器管理的事务，一个没有容器管理的事务：一个是资源本地的，另一个是 JTA。 我的代码需要使用正确的持久性单元，以便正确管理事务。

Answer 2

您可以查看WildFly 批处理快速入门，其中包含一些混合批处理、CDI 和 JPA 的有用示例，包括使用

@Inject

注入持久上下文。

对于 JBeret 的各种 CDI 范围的使用，这取决于您的具体用例。对于大多数批处理应用程序来说，他们可能不需要担心这一点。但是，如果您确实发现自己需要控制某些 CDI bean 的范围，那么请选择最适合 bean 的预期生命周期的范围。

如果你想在你的item writer中立即更新或删除它，你当然可以选择1的

item-count

。这是可行的，但效率会较低。