jpa一级缓存和二级缓存_了解一级JPA缓存

jpa一级缓存和二级缓存

我敢打赌，每个Java开发人员至少都听说过L1（又名EntityManager或Session）缓存。但是您的理解水平足够好吗？如果不确定，请考虑阅读这篇文章。

首先，我们需要知道持久性上下文是什么。根据EntityManager JavaDoc，我们知道：

“持久性上下文是一组实体实例，其中对于任何持久性实体标识，都有一个唯一的实体实例。 在持久性上下文中，管理实体实例及其生命周期。”

实际上，第一级缓存与持久性上下文相同。这意味着诸如persist（） ， merge（） ， remove（）之类的操作只会更改上下文中的内部集合，而不会同步到基础数据库。最重要的是，当您调用clear（）方法时会发生什么。清除L1缓存。但是我们知道L1 ==持久性上下文。这是否意味着清除L1会删除所有实体？实际上是的-所有实体都将被删除，并且永远不会同步到数据库。这不是秘密，它在文档中指出–” 对实体（…）进行的未经修改的更改将不会同步到数据库。 ”但是谁在乎文档呢？ :)

那么它在实践中看起来如何？看下面的代码：

em.persist(myEntity); // saves entity to the context
em.flush(); // triggers insert into database
em.clear(); // removes entity from the context == entity is no longer managed

如果省略flush（），则实体将不会访问数据库。它仅存在于您的代码中，并且在离开创建该对象的方法之后将丢失。让我们看下一个示例：

myEntity.setName("old name");
em.persist(myEntity);
em.flush();
em.clear();
myEntity.setName("new name");
em.flush();

完成此代码后， name属性的值是什么？当然仍然是“旧名称”，因为在调用setName（）的那一刻，该实体不再受管理，并且必须与持久性上下文合并（通过调用em.merge（myEntity）方法）才能成为主题肮脏的检查。

但是我没有在代码中调用flush（）方法，所以一切正常！但是，您是否调用clear（） ？我也这么想。默认的刷新行为是什么？默认情况下，JPA刷新提交以及每次查询执行时所做的更改（ FlushModeType.AUTO） 。如果将其更改为COMMIT（使用em.setFlushMode（FlushModeType.COMMIT）方法），则仅在提交时才会进行刷新（顾名思义）。

在处理批处理操作时，深入了解L1行为尤其重要。为什么？如果您希望这种操作有效，那么我们就必须不时手动刷新更改（假设每100次操作）。您知道吗，flush（）不会清除持久性上下文吗？那又如何呢？刷新并不便宜，因为它必须处理上下文中的所有实体，以查看是否有任何要与数据库同步的对象。如果您不会在flush（）之后立即手动清除上下文，则每个下一个操作将花费越来越长的时间。坦白地说，这一次呈指数增长，这似乎足以记住有关提到的技术。

如果您有兴趣深入了解持久性上下文，请随时克隆并使用此存储库，其中包含所有描述的案例和示例。