0

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

关于 1 级缓存的持久化上下文类型 Transaction-scoped Persistence context 和 Extended Persistence context 有什么区别？

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

现在，我的问题是：

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

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

4

1 回答 1

1

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

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

我可以主要想到两个原因，我更喜欢扩展的 EM 而不是事务性的：

  • 与外部系统或 UI 的通信。您可以操纵托管实体并使用尽可能少的移动部件来保存它们 - 不需要合并，甚至不需要显式保存。请参阅Adam Bien 的这个例子。

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

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

使用扩展 EM 有一些缺点

  • 如果事务回滚，则所有托管实体都将分离。将 PC 恢复到一致的可用状态可能很难完成。

  • 如果不小心使用，扩展的 PC 可能会被您不再需要的实体弄得杂乱无章。长期缓存可能包含大量陈旧数据。

  • 您可能需要一种用于刷新/重新获取托管实体的策略以及一种用于驱逐实体、类或完全清除缓存的策略。未能设计适当的策略可能会导致难以发现且难以重现的错误。适当的缓存失效 并非易事

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

我还不确定适当的storeMode设置retrieveMode。至于storeMode，我对它们的确切功能有些怀疑

于 2014-05-07T04:21:56.683 回答