当hibernate在二级缓存和具有各种缓存模式的DB之间执行同步时？ [英] When hibernate performs sync between second level cache and DB with various Cache modes?

问题描述

我一直在经历hibernate文档谈论二级缓存和查询缓存，并留下有关二级缓存同步到DB的问题，反之亦然。每个会话都可以定义自己的缓存模式，如NORMAL，GET，PUT和REFRESH。将会在所有情况下发生2L高速缓存 - 数据库同步，如果是这样，它会发生什么？

解决方案

来自海洋的DROP

谈到二级缓存，直接来到

usage-指定缓存策略：事务，读写，
非限制读写或只读

对于实体高速缓存，创建/更新/删除操作的顺序为：

DELETES：

  lock（java.lang.Object，java.lang.Object）
 evict（java.lang.Object）
 release（java.lang.Object，org.hibernate。 cache.CacheConcurrencyStrategy.SoftLock）
  

UPDATES：
$ b

  lock（java.lang.Object，java.lang.Object）
 update（java.lang.Object，java.lang.Object， java.lang.Object，java.lang.Object）
 afterUpdate（java.lang.Object，java.lang.Object，java.lang.Object，org.hibernate.cache.CacheConcurrencyStrategy.SoftLock）
  

INSERTS：

  insert（java.lang.Object，java.lang.Object，java.lang.Object）
 afterInsert（java.lang.Object，java.lang.Object，java.lang。对象）
  

对于集合缓存，所有修改操作实际上只是无效这里的调用顺序是：

  lock（java.lang.Object，java.lang.Object） 
 evict（java.lang.Object）
 release（java.lang.Object，org.hibernate.cache.CacheConcurrencyStrategy.SoftLock）
  

Nonstrict-R / w和R / W快取

每当会话开始时，向其添加时间戳（ST）
每当一个项目被加载到高速缓存中时，时间戳被添加到其中（CT）
现在，如果ST< CT，意味着会话比缓存的项目更旧，那么如果我们在这个较旧的会话中查找缓存的项目，Hibernate
将不会在缓存中查找。相反，它总是查看
数据库，因此在缓存中重新加载一个新的
时间戳。

对于非严格读写

•没有锁定。

•因此，当对象实际在数据库中更新时，在提交时（直到数据库完成提交），缓存具有旧对象，数据库具有新对象。

现在，如果任何其他会话寻找对象，它将在缓存中查找并找到旧的对象（ DIRTY READ ）

然而，一旦提交完成，对象将从缓存中逐出，以便下一个寻找对象的会话必须查看

对于读写尝试更新/删除项目，则项目在缓存中被软锁定，使得如果任何其它会话尝试寻找它，则必须去到数据库。

•现在，一旦更新结束并且数据已提交，缓存将使用新数据进行刷新，并释放锁定，以便其他事务现在可以查看CACHE，而无需转到数据库。

•所以，没有机会读取脏，任何会话几乎总是从数据库/缓存读取提交数据。

总结：

ReadOnly快取只能执行读取和插入操作，无法执行
更新/删除。速度最快。

Nonstrict读写缓存不使用任何锁，所以
总是有脏读的机会。然而，它总是从高速缓存中驱出
条目，因此任何后续的访问总是引用DB的
。

读写缓存使用锁，但以异步方式，首先
插入/更新/删除发生在tx中w /。当缓存条目是
时，软锁并且其他会话必须引用数据库。一旦
tx。完成后，锁释放并且缓存
更新（在事务外部）。在某些情况下，可重复读取
可能会被破坏。

事务缓存显然更新数据库和缓存
在同一个事务中，因此它总是与
一致的状态尊重数据库。

实体类型大部分更新，并且有并发读取和
更新，读写缓存策略可能不是很有用，因为大多数
读取将被偏转到数据库

查询缓存

属性在我们的hibernate.cfg.xml
1

true

此设置创建两个新的缓存区域：

org.hibernate.cache.StandardQueryCache ，持有缓存的查询结果

org.hibernate.cache.UpdateTimestampsCache ，保存可查询表的最近更新的时间戳。这些用于在从查询缓存中提供结果时验证结果。

查询缓存不缓存缓存中实际实体的状态;它仅缓存值类型的标识符值和结果。由于这个原因，查询缓存应该总是与第二级缓存结合使用，用于希望作为查询结果缓存的一部分缓存的那些实体。

I have been going through hibernate documentation talking about second level cache and query cache and left with questions regarding the second level cache sync to DB and vice verse. Every session can define its own cache mode say NORMAL, GET, PUT and REFRESH. Will 2L cache <-> DB sync happens in all cases, If so when it will happen exactly? Thanks much in advance.

解决方案

A DROP FROM AN OCEAN

Talking about 2nd Level cache, directly comes to

usage- specifies the caching strategy: transactional, read-write, nonstrict-read-write or read-only

In terms of entity caches, the expected call sequences for Create / Update / Delete operations are:

DELETES :

lock(java.lang.Object, java.lang.Object)
evict(java.lang.Object)
release(java.lang.Object, org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)

UPDATES :

lock(java.lang.Object, java.lang.Object)
update(java.lang.Object, java.lang.Object, java.lang.Object, java.lang.Object)
afterUpdate(java.lang.Object, java.lang.Object, java.lang.Object,org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)

INSERTS :

insert(java.lang.Object, java.lang.Object, java.lang.Object)
afterInsert(java.lang.Object, java.lang.Object, java.lang.Object)

In terms of collection caches, all modification actions actually just invalidate the entry(s).The call sequence here is:

lock(java.lang.Object, java.lang.Object)
evict(java.lang.Object)
release(java.lang.Object, org.hibernate.cache.CacheConcurrencyStrategy.SoftLock)

Nonstrict-R/w and R/W cache

Whenever a session starts, a timestamp is added to it.(ST) Whenever an item is loaded in the cache, a timestamp is added to it.(CT) Now if ST < CT, meaning the session is older than the cached item, then if we look for the cached item in this older session, Hibernate will NOT look in the cache. Instead it will always look in the database, and consequently re-load the item in the cache with a fresh timestamp.

For NonStrict-Read-Write

• There’s no locking ever.

• So, when the object is actually being updated in the database, at the point of committing(till database completes the commit), the cache has the old object, database has the new object.

• Now, if any other session looks for the object , it will look in the cache and find the old object.(DIRTY READ)

• However, as soon as the commit is complete, the object will be evicted from the cache, so that the next session which looks for the object, will have to look in the database.

For Read-Write

• As soon as somebody tries to update/delete an item, the item is soft-locked in the cache, so that if any other session tries to look for it, it has to go to the database.

• Now, once the update is over and the data has been committed, the cache is refreshed with the fresh data and the lock is released, so that other transactions can now look in the CACHE and don’t have to go to the database.

• So, there is no chance of Dirty Read, and any session will almost ALWAYS read READ COMMITTED data from the database/Cache.

To summarize:

ReadOnly cache can do only reads and inserts , cannot perform updates/deletes. Fastest performing.

Nonstrict Read Write Cache doesn’t employ any locks, ever, so there’s always a chance of dirty reads. However, it ALWAYS evicts the entry from the cache so that any subsequent sesssions always refer to the DB.

Read Write cache employs locks but in an asynchronous manner, first the insert/update/delete occurs w/in the tx. When the cache entry is softlocked and other sessions have to refer to the database. Once the tx. is completed, the lock is released and the cache is updated.(outside the transaction). In some cases, repeatable reads might be compromised.

Transactional caches obviously update the database and the cache within the same transaction, so its always in a consistent state with respect to the database.

Entity type that are mostly updated and have got concurrent read and updates, read-write caching strategy may not be very useful as most of the reads will be deflected to database

Query Cache

e need to enable the below property in our hibernate.cfg.xml 1

true

This setting creates two new cache regions:

org.hibernate.cache.StandardQueryCache, holding the cached query results

org.hibernate.cache.UpdateTimestampsCache, holding timestamps of the most recent updates to queryable tables. These are used to validate the results as they are served from the query cache.

Query cache does not cache the state of the actual entities in the cache; it caches only identifier values and results of value type. For this reason, the query cache should always be used in conjunction with the second-level cache for those entities expected to be cached as part of a query result cache

这篇关于当hibernate在二级缓存和具有各种缓存模式的DB之间执行同步时？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！