0

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#removeJPQL 选择查询（Query#getResultList和Query#getSingleResult）时才插入缓存的内容。但是，如果我们执行了 JPQL 更新或删除查询（），我们不应该推缓存。Query#executeUpdate为了 Java EE 新手的利益，应该添加其他应用程序进程和直接数据库调用 (JDBC) 也可以使缓存无效。不管这是否属实，还有一件事我无法理解：

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

有知道的给我吧！！

4

1 回答 1

1

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

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

于 2013-04-10T07:31:22.443 回答