0

我有一些用于与 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会出现三个范围：作业、步骤和分区。由于我运行了太长时间的批处理，我可能需要分区范围，但是批处理将如何控制分区？
  • 我了解到读取器/处理器/写入器模式控制大量记录的事务 ootb。该模式是否适用于读取记录、处理它然后立即更新或删除它的代码？
4

2 回答 2

1

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

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

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

于 2021-03-06T23:41:26.980 回答
0

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

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

如果您想立即在您的项目编写器中更新或删除它，您当然可以选择item-count1。这是可行的，但效率会降低。

于 2021-03-02T14:03:03.927 回答