Dear all,

We are currently using Hibernate 3.1, with great results, on a clustered Weblogic application server and Oracle 10G. To increase perfromance we are looking at implementing second level caching.

I was wondering if any one could help me in the following areas:

1. Which cache is best to use in a clustered environment?

Looking at the hibernate documentation Swarm cache supports clusters, however, according to EHCache documentation it also supports clustered environments. Ideally i'd like a cache that replicates information to the other node in the cluster, i.e. when I write a record it gets replicated to the other node.

2. How does Hibernate query the cache?

Looking at the documentation hibernate uses the primary key of the table as the cache key. What happens if you want to query on a different value? By default will the whole cache be iterated through, or will hibernate go to the database to satisfy the query?

3. Is it possible to change the cache key to a value other than the pk of the table?

Cheers

Ed

I'm no expert but my guess is that it really depends on how transactional you want to get. Sure, lots of caches will communicate changes from one JVM to another (i.e. between members of the cluster). The hard part is: what level of isolation can they guarantee you while doing that? From my reading of Hibernate in Action, I believe only JBossCache can handle things fully transactionally, and I dont know even if it can work concurrently with a legacy app hitting the same data on the same database. Consider this: say you want to read data items A and B, make some decisions based on those values and write out B. If there were no cache, you would do this in a direct transaction to the DB. If the DB were running at repeatable read isolation, it would read-lock A and B for you when you read them (thereby making sure that no one could write A and B while you were making your decisions - if they did, they might invalidate your decisions), and then write lock B when you write out B (so that no one could even read your uncommitted change - you might yet choose to abort), and then finally commit everything and release all locks when you hit commit, in a single atomic swoop. Sound good?

Now, when an SLC comes into the picture, when you read A and B, I assume the transactional SLC will return you the values of A and B and read lock them. To correctly do this, it must communicate the fact that it has read locked A and B to all the members (other JVMs) in the cluster. Next when you update B, it must do the same with a write lock. Then when you commit, it can make your changes visible to all other SLCs in the cluster (atomically of course, with all the handshakes that entails), and also write your changes out to the DB.

A non-transactional SLC doesnt guarantee all of this. EHCache in my understanding will let you read without read locking (so you dont know that you're getting the latest changes that have been made in other JVMs) and when you write, it probably simply writes out to DB and to cache at the same time and propagates those changes asynchronously to the other caches in the cluster. In short, isolation is very iffy.

However, this might work for you, and it will certainly perform much better. So there is no clear answer to yr q. If your access patterns are such that they can deal with the loose consistency of a non-transactional SLC, you are in great shape. Otherwise, you might need the transactional one in which case you might really need to evaluate whether the transactional SLC really does improve yr perf or not. This is why I suspect the Hibernate guys arent too hot on SLCs (as I gather from the book, maybe their views have changed)

Anyway, as I said, I'm not an expert. I'm simply posting to get some of my ideas out and hear from you and others and the Hibernate team so that we all get some clarity on these issues. I feel the book HIA and the doc dont give full clarity here hence a discussion is of much value.

Later, hope this helps, please give me credit if it does, I expect to run into several issues in the near future, and I probably need credits to post queries..

Sundeep