Which JVM cache? What about nonstrict read/write caching?

hypernate · **Posted:** Wed Jul 28, 2004 11:40 am

My dev team is using Hibernate 2.1.4 and about to enable JVM caching (we're not using JTA) and have two principal questions:

1. Which cache provider should we use? We don't require clustering (yet) and so EHCache and OSCache are the most likely candidates... but I'm curious if anyone has any positive/negative experiences to share or if anyone can point me to an online comparison of the various cache providers.

2. What exactly are the semantics of nonstrict read/write caching, which the docs define as follows:

Quote:

If the application only occasionally needs to update data (ie. 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.

What is the behavior if two transaction concurrently insert/update/delete the same item? Does one fail, do they both succeed, or is the behavior nondeterministic?

We'll test this ourselves, of course, to ensure the cache is configured and behaving as we require, but it would be great to have a better understanding of the intended behavior.

christian · **Posted:** Wed Jul 28, 2004 11:41 am

The behavior is that one transaction invalidates/updates the item in the cache, while there is still a posibility that the concurrent transaction will get the stale item. The invalidation is an asynchronous operation, without any locking.

hypernate · **Posted:** Wed Jul 28, 2004 12:00 pm

Thanks!

So nonstrict read/write is appropriate if you don't require absolute protection from dirty reads, or if the odds of concurrent access are so slim that you're willing to accept an occassional dirty read.

Of course, same goes for dirty writes, since if one's not protected from dirty reads then one is also not protected from dirty writes.