When hibernate performs sync between second level cache and DB with various Cache modes?

Question

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.

Answer 1

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