为什么在执行修改查询之前需要清除jpa持久性上下文？
我正在使用Spring Boot 1.5.2。发布和一个PostgreSQL 9.5数据库。
文件实体：
java prettyprint-override">@Entity
public class File implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String externalUid;
}
文件存储库看起来像：
public interface FileRepository extends JpaRepository<File, Long> {
@Modifying
@Query("UPDATE File f SET f.externalUid =:externalUid WHERE f.id =:id")
void setExternalLink(@Param("id") Long id, @Param("externalUid") String externalId);
}
当我保存新文件（使用flush）并对其执行更新，然后从存储库获取该文件后，我就有了过时的实体。但是，当我在执行修改查询之前在entityManager上执行clear（）[1]时，我会得到更新的实体：
String externalUid = UUID.randomUUID().toString();
File file = new File();
File savedFile = fileRepository.saveAndFlush(file);
// [1] entityManager.clear();
fileRepository.setExternalLink(savedFile.getId(), externalUid);
File updatedFile = fileRepository.findOne(savedFile.getId());
System.out.print(updatedFile.getExternalUid()); // null
这个问题与这个问题非常相似：Spring Boot数据JPA-修改更新查询-刷新持久性上下文。但在我的例子中，我执行的是saveAndFlush（），而不是save（）。
在这方面，有人能解释一下为什么我们需要在执行修改查询之前清除持久性上下文，为什么存储库会返回过时的实体？
共有1个答案
要点是Hibernate缓存不知道你所做的DML风格的查询。
因此，如果不清除缓存并直接在数据库上执行更新，所涉及的缓存对象将过时。
调用clear（）将清空缓存，并强制hibernate在后续查询中点击数据库。
-
当使用修改查询时，我有一个问题，EntityManager在查询执行后包含过时的实体。 假设我们在DB中有电子邮件[ID=1,active=true,expire=2015/01/01]。 执行后：
-
问题内容： 我是Java世界和JPA的新手。我在学习JPA时遇到了许多新术语，例如Entity，persistence。在阅读时，我无法理解 Persistence Context 的确切定义。 谁能用简单的外行术语解释它？与中使用的数据有什么关系？ 例如，我发现此定义太复杂而难以理解： 持久性上下文是一组实体，因此对于任何持久性标识，都有一个唯一的实体实例。 问题答案： 持久性上下文处理一组实体
-
持久性上下文是一组实体，因此对于任何持久性标识都有一个唯一的实体实例。
-
Vlad关于如何修复MultipleBagsException的示例将是我们的起点：如何修复MultipleBagsException-Vlad Mihalcea EntityManager的定义如下： 那么，为什么我们需要启动事务以便启用PersistenceContext，即使我们将其设置为使用扩展上下文呢？
-
问题内容： 我正在尝试学习pthread_cond_wait的基础知识。在所有用法中，我都可以看到 要么 我的问题是，我们只想cond_wait因为条件为假。那我为什么要忍受明确地放置一个if / while循环的痛苦。我可以理解，在不进行任何if / while检查的情况下，我们将直接击中它，根本不会返回。条件检查是仅用于解决此目的，还是具有其他意义。如果它用于解决不必要的条件等待，则进行条件检
-
有一种方法可以绕过持久性上下文，只将实体用作数据库表的包装器？