2nd-level cache: read/write vs. nonstrict read/write

sschaub · **Joined:** Wed Sep 27, 2006 4:07 pm **Posts:** 9

I am new to Hibernate and have a question regarding the 2nd-level cache feature.

Environment: Hibernate 3.2CR2 with SQL Server 2005

I have a simple persistent class named Event, and I have enabled caching for it. Here is a code fragment that illustrates a load, followed by an update, then another load:

Code:

Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
Event anEvent = (Event) session.load(Event.class, new Long(1));
System.out.println(anEvent.getTitle());
anEvent.setTitle(anEvent.getTitle() + "*");
session.getTransaction().commit();

session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
anEvent = (Event) session.load(Event.class, new Long(1));
System.out.println(anEvent.getTitle());
session.getTransaction().commit();

Using the org.hibernate.cache.HashtableCacheProvider cache provider, if I specify a cache strategy "nonstrict read/write", the second load issues a second SELECT (cache is not used). But if I use the cache strategy "read/write", the second load appears to retrieve the object from cache (the desirable behavior).

Can someone explain the difference between the two strategies, and why I am observing the behavior I see? I have found a couple of other posts about this, but none comparing these two strategies.

Thanks in advance!

sschaub · **Joined:** Wed Sep 27, 2006 4:07 pm **Posts:** 9

Well, I dug through the source code this morning and believe I found my answer.

org.hibernate.cache.NonstrictReadWriteCache, which implements the nonstrict-read-write cache strategy, appears to evict items from the cache when they are updated. That would explain the behavior I observed.

On the other hand, org.hibernate.cache.ReadWriteCache does not evict items when they are updated. Instead, as I understand the code, ReadWriteCache internally timestamps items added to the cache and returns them only when they haven't been updated since the start of the current transaction.

Can someone confirm this analysis?

I admit I'm puzzled by the behavior of NonstrictReadWriteCache. Why does it invalidate cache items on update? I think I need a better understanding of caching concepts.

HamsterofDeath · **Joined:** Fri Sep 01, 2006 3:35 pm **Posts:** 21

same here, but even worse: hibernate completely refuses to use the cache. it's filled, but never read from. just the query cache works.

i can hardly find any documentation about the second level cache. is it such a hated feature?

HamsterofDeath · **Joined:** Fri Sep 01, 2006 3:35 pm **Posts:** 21

i just debugged a lot and found the reason why hibernate does not access the 2nd level cache. it's NEVER done when accessing objects by querying them - only by accessing them via session.get() by their primary key and indirectly when loading them lazily.

jaikiran · **Joined:** Wed Jul 27, 2005 2:33 am **Posts:** 118

Yes you are right, the Hibernate second level cache comes into picture when you use the API available on the Session. Here's an article that explains the second level cache:

http://www.javalobby.org/java/forums/t48846.html

jcarreira · **Joined:** Thu Oct 09, 2003 4:06 pm **Posts:** 16

sschaub wrote:

Well, I dug through the source code this morning and believe I found my answer.

org.hibernate.cache.NonstrictReadWriteCache, which implements the nonstrict-read-write cache strategy, appears to evict items from the cache when they are updated. That would explain the behavior I observed.

On the other hand, org.hibernate.cache.ReadWriteCache does not evict items when they are updated. Instead, as I understand the code, ReadWriteCache internally timestamps items added to the cache and returns them only when they haven't been updated since the start of the current transaction.

Can someone confirm this analysis?

I admit I'm puzzled by the behavior of NonstrictReadWriteCache. Why does it invalidate cache items on update? I think I need a better understanding of caching concepts.

The reason the nonstrict read/write cache works that way is that it's often used for caches in a cluster where the cache implementation is a simple multicast-invalidation cache like swarmcache or oscache. For read-write caching in a cluster you need Tangosol Coherence or JBoss Cache, which do the work to keep the caches on the different cluster nodes in-sync. If you're only running on a single node, I think you're ok using the read-write cache strategy for some of the cache providers (EHCache, for instance). Look at the docs for those cache providers for the definitive answers on that.

sschaub · **Joined:** Wed Sep 27, 2006 4:07 pm **Posts:** 9

jcarreira wrote:

The reason the nonstrict read/write cache works that way is that it's often used for caches in a cluster where the cache implementation is a simple multicast-invalidation cache like swarmcache or oscache.

This makes sense. Thanks for the explanation.

anirban · **Joined:** Sat Sep 13, 2008 9:45 am **Posts:** 4

Hi, I have created a post here(http://anirbanchowdhury.wordpress.com/2 ... e-ehcache/) explaining the differences. Please have a look and feel free to comment.