java – Hibernate缓存策略

我如何决定使用哪个CacheConcurrencyStrategy？

> NonstrictReadWriteCache,
> ReadOnlyCache,
> ReadWriteCache,
> TransactionalCache.

我读了https://www.hibernate.org/hib_docs/v3/api/org/hibernate/cache/CacheConcurrencyStrategy.html,但没有详细解释.

解决方法:

Hibernate documentation在定义它们方面做得非常好：

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_class
and 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.

换一种说法：

>只读：对于经常读取但从未更新的数据(例如国家/地区等参考数据)非常有用.很简单.它具有最好的表现(显然).
>读/写：如果您的数据需要更新,则需要.但它没有提供SERIALIZABLE隔离级别,phantom reads可能会发生(您可能会在交易结束时看到一些开头没有的东西).它具有比只读更多的开销.
>非严格读/写：或者,如果两个单独的事务线程不可能更新同一个对象,则可以使用非严格读写策略.它具有比读写更少的开销.这个对于很少更新的数据很有用.
> Transactional：如果您需要完全事务缓存.仅适用于JTA环境.

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

标签：java,orm,hibernate,ehcache,second-level-cache
来源： https://codeday.me/bug/20190930/1834350.html