Java 休眠缓存策略

Hibernate cache strategy

提问by cometta

How do I decide which CacheConcurrencyStrategyto use?

我如何决定CacheConcurrencyStrategy使用哪个？

• NonstrictReadWriteCache,
• ReadOnlyCache,
• ReadWriteCache,
• TransactionalCache.

• NonstrictReadWriteCache,
• ReadOnlyCache,
• ReadWriteCache,
• TransactionalCache.

I read https://www.hibernate.org/hib_docs/v3/api/org/hibernate/cache/CacheConcurrencyStrategy.html, but doesn't explain in detail enough.

我阅读了https://www.hibernate.org/hib_docs/v3/api/org/hibernate/cache/CacheConcurrencyStrategy.html，但解释得不够详细。

采纳答案by Pascal Thivent

The Hibernate documentationdoes a pretty good job at defining them:

在Hibernate文档确实在他们定义了很好的工作：

19.2.2. Strategy: read only

If your application needs to read, but not modify, instances of a persistent class, a read-only cache can be used. This is the simplest and optimal performing strategy. It is even safe for use in a cluster.

19.2.3. Strategy: read/write

If the application needs to update data, a read-write cache might be appropriate. This cache strategy should never be used if serializable transaction isolation level is required. If the cache is used in a JTA environment, you must specify the property hibernate.transaction.manager_lookup_classand naming a strategy for obtaining the JTA TransactionManager. In other environments, you should ensure that the transaction is completed when Session.close()or Session.disconnect()is called. If you want to use this strategy in a cluster, you should ensure that the underlying cache implementation supports locking. The built-in cache providers do not support locking.

19.2.4. Strategy: nonstrict read/write

If the application only occasionally needs to update data (i.e. if it is extremely unlikely that two transactions would try to update the same item simultaneously), and strict transaction isolation is not required, a nonstrict-read-write cache might be appropriate. If the cache is used in a JTA environment, you must specify hibernate.transaction.manager_lookup_class. In other environments, you should ensure that the transaction is completed when Session.close()or Session.disconnect()is called.

19.2.5. Strategy: transactional

The transactional cache strategy provides support for fully transactional cache providers such as JBoss TreeCache. Such a cache can only be used in a JTA environment and you must specify hibernate.transaction.manager_lookup_class.

19.2.2. 策略：只读

如果您的应用程序需要读取而不是修改持久类的实例，则可以使用只读缓存。这是最简单和最佳的执行策略。在集群中使用它甚至是安全的。

19.2.3. 策略：读/写

如果应用程序需要更新数据，读写缓存可能是合适的。如果需要可序列化的事务隔离级别，则永远不应使用此缓存策略。如果在 JTA 环境中使用缓存，则必须指定属性 hibernate.transaction.manager_lookup_class并命名获取 JTA 的策略TransactionManager。在其他环境中，您应该确保事务在Session.close()或 Session.disconnect()被调用时完成 。如果要在集群中使用此策略，则应确保底层缓存实现支持锁定。内置缓存提供程序不支持锁定。

19.2.4. 策略：非严格读/写

如果应用程序只是偶尔需要更新数据（即如果两个事务极不可能同时更新同一个项目），并且不需要严格的事务隔离，那么非严格读写缓存可能是合适的。如果在 JTA 环境中使用缓存，则必须指定 hibernate.transaction.manager_lookup_class. 在其他环境中，您应该确保事务在Session.close()或 Session.disconnect()被调用时完成。

19.2.5. 策略：交易

事务缓存策略为完全事务缓存提供程序（如 JBoss TreeCache）提供支持。这种缓存只能在 JTA 环境中使用，您必须指定 hibernate.transaction.manager_lookup_class.

In other words:

换句话说：

• Read-only:Useful for data that is read frequently but never updated(e.g. referential data like Countries). It is simple. It has the best performances of all (obviously).

• Read/write:Desirable if your data needs to be updated. But it doesn't provide a SERIALIZABLEisolation level, phantom readscan occur (you may see at the end of a transaction something that wasn't there at the start). It has more overhead than read-only.

• Nonstrict read/write:Alternatively, if it's unlikely two separate transaction threads could update the same object, you may use the nonstrict–read–write strategy. It has less overhead than read-write. This one is useful for data that are rarely updated.

• Transactional:If you need a fully transactionalcache. Only suitable in a JTA environment.

• 只读：适用于经常读取但从未更新的数据（例如国家/地区等参考数据）。很简单。它具有最好的性能（显然）。

• 读/写：如果您的数据需要更新，则可取。但是它不提供SERIALIZABLE隔离级别，可能会发生幻读（您可能会在事务结束时看到开始时不存在的内容）。它比只读有更多的开销。

• 非严格读/写：或者，如果两个单独的事务线程不太可能更新同一个对象，您可以使用非严格读写策略。它的开销比读写少。这对于很少更新的数据很有用。

• 事务性：如果您需要完全事务性的缓存。仅适用于 JTA 环境。

So, choosing the right strategy depends on the fact that data are being updated or not, the frequency of updates and the isolation level required. If you don't know how to answer these questions for the data you want to put in cache, maybe ask some support from a DBA.

因此，选择正确的策略取决于数据是否正在更新、更新频率和所需的隔离级别。如果您不知道如何回答要放入缓存中的数据的这些问题，请向 DBA 寻求支持。

回答by Adeel Ansari

Reading API Docs is good thing, but you should also read the documentation (its awesome) also, Second Level Cache - Strategies.

阅读 API 文档是一件好事，但您也应该阅读文档（它很棒），二级缓存策略。

回答by Nitin Pawar

READ_ONLY:Used only for entities that never change (exception is thrown if an attempt to update such an entity is made). It is very simple and performant. Very suitable for some static reference data that don't change.

READ_ONLY：仅用于永不更改的实体（如果尝试更新此类实体，则会引发异常）。它非常简单且高效。非常适合一些不变的静态参考数据。

NONSTRICT_READ_WRITE:Cache is updated after a transaction that changed the affected data has been committed. Thus, strong consistency is not guaranteed and there is a small time window in which stale data may be obtained from cache. This kind of strategy is suitable for use cases that can tolerate eventual consistency.

NONSTRICT_READ_WRITE：在提交更改受影响数据的事务后更新缓存。因此，无法保证强一致性，并且有一个小的时间窗口可以从缓存中获取陈旧数据。这种策略适用于可以容忍最终一致性的用例。

READ_WRITE:This strategy guarantees strong consistency which it achieves by using ‘soft' locks: When a cached entity is updated, a soft lock is stored in the cache for that entity as well, which is released after the transaction is committed. All concurrent transactions that access soft-locked entries will fetch the corresponding data directly from database.

READ_WRITE：此策略通过使用“软”锁来保证强一致性：当缓存实体更新时，软锁也会存储在该实体的缓存中，并在事务提交后释放。所有访问软锁定条目的并发事务都将直接从数据库中获取相应的数据。

TRANSACTIONAL:Cache changes are done in distributed XA transactions. A change in a cached entity is either committed or rolled back in both database and cache in the same XA transaction.

TRANSACTIONAL：缓存更改在分布式 XA 事务中完成。缓存实体中的更改在同一 XA 事务中的数据库和缓存中提交或回滚。

回答by Nithin Prasad

1. Transactional ? Use this strategy for read-mostly data where it is critical to prevent stale data in concurrent transactions, in the rare case of an update.

2. Read-write ? Again use this strategy for read-mostly data where it is critical to prevent stale data in concurrent transactions, in the rare case of an update.

3. Nonstrict-read-write ? This strategy makes no guarantee of consistency between the cache and the database. Use this strategy if data hardly ever changes and a small likelihood of stale data is not of critical concern.

4. Read-only ? A concurrency strategy suitable for data, which never changes. Use it for reference data only.

1. 交易 ? 将此策略用于主要读取数据，在这种情况下，在极少数更新的情况下，防止并发事务中的陈旧数据至关重要。

2. 读写 ? 再次使用此策略读取主要数据，在这种情况下，在极少数更新的情况下，防止并发事务中的陈旧数据至关重要。

3. 非严格读写 ? 此策略不保证缓存和数据库之间的一致性。如果数据几乎不会发生变化并且过时数据的可能性很小，则使用此策略不是关键问题。

4. 只读 ？适用于数据的并发策略，永不改变。仅用作参考数据。

Hope this clears your doubt!

希望这能消除你的疑惑！