在JPA中配置1级和2级缓存

Question

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

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

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

现在，我的问题是：

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

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

Answer 1

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

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

我可以想到主要有两个理由来选择扩展EM而非交易策略：

• 与外部系统或UI进行通信。您可以操纵管理实体并使用尽可能少的移动部件保存它们 - 不需要合并，甚至不需要显式保存。见Adam Bien的this example。

• 模仿会话范围 - 使用跨越多个HTTP请求的单个事务是不切实际的，因此可以使用扩展PC。示例here和here

• 一个很少写入数据但很频繁读取的应用程序。如果您有理由相信数据不会发生变化，您可以获得缓存实体以进行频繁读取的好处，而不是每次都从DB中获取数据。

使用扩展EM

有一些缺点

• 如果回滚了一个事务，则所有管理实体都会被分离。将PC恢复到一致的可用状态可能很难实现。

• 如果使用不小心，扩展的PC可能会混乱您不再需要的实体。长生存缓存可能包含大量陈旧数据。

• 您可能需要一种策略来刷新/重新获取托管实体，以及一种驱逐实体，类或完全清除缓存的策略。如果没有设计合适的策略，可能会导致难以发现并且难以重现的错误。适当的缓存失效is not trivial

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

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