JPA中一级和二级缓存的配置答案

【问题标题】：Configuration of Level 1 and Level 2 cache in JPAJPA中一级和二级缓存的配置
【发布时间】：2014-06-21 01:37:36
【问题描述】：

我已阅读以下页面，但我有几个疑问。

关于一级缓存的持久化上下文类型 What is the difference between Transaction-scoped Persistence context and Extended Persistence context?

关于二级缓存 http://www.objectdb.com/java/jpa/persistence/cache

现在，我的问题是：

在正常情况下，最好的 PersistenceContextType 是什么选择 L1 缓存、TRANSACTION 还是 EXTENDED？我想答案是 TRANSACTION，因为它是默认值。但是我想知道什么时候我应该使用 EXTENDED。
在正常情况下，为 L2 缓存的以下属性：
- javax.persistence.sharedCache.mode（我想答案是 ALL，因为它是默认设置并缓存所有实体）
- javax.persistence.cache.retrieveMode（我想答案是 USE，因为它是默认设置并在检索时使用缓存）
- javax.persistence.cache.storeMode（我想答案是 USE，因为它是默认设置，但我仍然不明白与 REFRESH 的区别，这对我来说似乎更好）

有人可以解释如何正确地正确放置 L1 和 L2 的这些属性，并解释何时使用某些值或其他值吗？

【问题讨论】：

【解决方案1】：

注意：此答案尚未完成，我将更新 WRT 缓存模式的详细信息

使用 Java EE 时，默认持久性上下文 (PC) 设置为 TRANSACTION。这也是几乎所有任务的最佳模式。由于它的使用寿命相对较短，因此具有维护成本低或零维护的优点。

我认为首选扩展 EM 而非事务性 EM 的原因主要有两个：

与外部系统或 UI 的通信。您可以操纵托管实体并使用尽可能少的移动部件来保存它们 - 不需要合并，甚至不需要显式保存。请参阅 Adam Bien 的 this example。
模拟会话范围 - 使用跨越多个 HTTP 请求的单个事务是不切实际的，因此可以使用扩展的 PC。示例here 和here
很少写入数据但读取非常频繁的应用程序。如果您有理由相信数据不会发生变化，您可以获得缓存实体以供频繁读取的好处，而不是每次都从数据库中获取它们。

使用扩展的 EM 有一些缺点

如果事务回滚，所有托管实体都将分离。将 PC 恢复到一致的可用状态可能非常困难。
如果不小心使用，扩展 PC 可能会被您不再需要的实体弄得杂乱无章。长期缓存可能包含大量陈旧数据。
您可能需要一个用于刷新/重新获取托管实体的策略以及一个用于逐出实体、类或完全清除缓存的策略。未能设计适当的策略可能会导致难以发现且难以重现的错误。正确的缓存失效is not trivial

因此，如果使用扩展 EM，请将其用于单一目的，这样您就可以更轻松地推断缓存的内容。

我还不确定适当的 storeMode 和 retrieveMode 设置。至于storeMode，我有一些doubts about their exact function

【讨论】：