JPQL 查询和 JPA 持久性上下文中的批量更新是什么？答案

【问题标题】：What is a bulk update in the context of JPQL queries and JPA persistence context?JPQL 查询和 JPA 持久性上下文中的批量更新是什么？
【发布时间】：2013-04-01 03:22:43
【问题描述】：

JPA 2.0 规范 (JSR 317) 说：

The persistence context is not synchronized with the result of the bulk update or delete.

究竟什么是批量更新？

在我看来，[或者更确切地说应该]“批量更新”和“定期更新”之间存在区别。我想相信批量更新是更新多个实体的更新。因此，应该有一个不被归类为“批量”的更新，一种只针对一个实体的更新操作。而在这种情况下，该操作是否更新一级缓存非常重要。

规范从来没有解决这个问题，也没有对“批量更新”这个词给出明确的定义。我也找不到关于该主题的任何其他来源。我尽力测试了一个应用程序管理的资源本地实体管理器（使用 EclipseLink 2.3.2.v20111125-r10461），并且可以确认持久性上下文确实已过时，即使我们执行仅针对一个单一实体的更新查询. JPA 提供程序也没有调用我附加到测试类的实体侦听器。

在阅读 JPA 2.0 规范后，我假设这仅适用于“批量更新”，即更新针对受影响行大于 1 的多个实体的查询。但考虑到前面描述的测试结果我开始认为没有“定期更新”之类的东西，所有更新查询都是“批量更新”。

如果这是真的，那么故事的寓意就是仅在我们执行 EntityManager#find、EntityManager#merge、EntityManager#remove 和 JPQL 选择查询（Query#getResultList 和 Query#getSingleResult）时才插入缓存的内容。但是，如果我们执行了 JPQL 更新或删除查询 (Query#executeUpdate)，我们应该不推入缓存。为了 Java EE 新手的利益，应该添加其他应用程序进程和直接数据库调用 (JDBC) 也可以使缓存无效。不管这是否属实，还有一点我无法理解：

此设计背后的基本原理是什么，为什么 JPA 提供者不应该同步持久性上下文和/或他的二级缓存？我的第一个猜测是性能原因，但话又说回来，我不知道。

如果你知道什么，给我！！

【问题讨论】：

反对者愿意分享他的推理吗？

标签： jakarta-ee jpa sql-update jpql second-level-cache

【解决方案1】：

“BULK UPDATE”显然是使用诸如“UPDATE MyEntity SET field1 = val1 WHERE field2 < 345”之类的查询的更新（就像 BULK DELETE 是一个 DELETE 查询一样）。正常更新是您使用 setter 直接更新托管实体的字段。

基本原理：批量更新的全部意义在于不必将对象加载到内存中，或者确定是否已经管理了任何受影响的对象。您可能会发现大多数 JPA 实现会在执行 BULK UPDATE 时将可能受影响的对象逐出 L2 缓存。

【讨论】：

是的，但这就是问题所在！当我们知道myId 是具有唯一约束的主键时，您是否认为UPDATE Entity e SET e.myId = 'XXX' WHERE e.myId = 'YYY' 是一个批量更新？当然，这个查询只会影响一行。因此，如果规范说 bulk 更新，受影响的行数大于 1 的查询，那么像我描述的查询应该与缓存同步！似乎已经达成共识，所有更新和删除语句都会使缓存无效，但这也许不是规范的要求？
关于性能的好点。就像我当时想的那样，但我在已发布的文档中找不到任何相关信息。
我认为通过查询进行的任何 UPDATE 都是“批量”（即使它们不更新超过 1 个对象），因为它具有通用过滤器。个别实现可能会或可能不会检查更新的逻辑以确定是否正在更新超过 1 个对象，并决定将更改应用于该对象（如果受管理，但规范 IIRC 不要求）
嗯。如果您有时间，您能否快速进行谷歌搜索，看看您是否可以提出任何已发布的文档，其中明确定义了批量更新是什么以及为什么它在这种情况下可能很重要？我确实没有发现任何东西，我对某事以某种特定方式“只是”感到不舒服。
您写道：“您可能会发现大多数 JPA 实现会在执行 BULK UPDATE 时将可能受影响的对象逐出 L2 缓存。”