I have just had a worry regarding fail-over/load balancing and use of secondary cache.

Scenario:

- The user starts a session, which is allocated to Server A.
- Several pages are navigated, and the data are stored to hibernate
- Load on the system is high and the Webserver allocates the next request to Server B.
- The user returns to an earlier page, the data are correctly displayed, having not been in the cache and therefore retrieved from the database.
- The user alters some value and navigates off the page, the value is saved to the database
- The next request is serviced from server A and returns again to the earlier page.

In this scenario we need to detect that the session has switched server and force hibernate to ignore the secondary cache for that query (however we want it cached for future calls). How is this best achieved, we are using EHCache and Websphere.

Many thanks, Pete.

it is not a specific problem about hibernate, not all caches can be used in clustered environement.
Take a look at Tangosol Coherence cache.

If you can't use a clusterisable cache, i'll advise you not to use second level cache.

Have you studied JBoss option? i think it's a good way to deal with cluster, cost and high performance

Haven't studied the JBoss cache, how does this manage the problem? I'm guessing I can't use the JBoss cache with Websphere?

I have an option which is to place a transient object in the session, if that object does not exist then I know the session has been de-serialized, in which case I can't trust the secondary cache and want to force a read from the database. Is this possible? I don't really want to clear the whole cache, just for that query.

oh excuse me, i've read too fast and have not seen about websphere.
The problem is to define a mechanism that is 100% secure and that doesn't cost too much. Are you using EJB or pojo in websphere?

When you use a de-serialized session, does this session succeed in recovering its connection? How are you doing this?

This particular issue is using POJO's in the WebApplication, we have two clusters each with the web application deployed and are using persistent sticky http sessions. In most cases we won't have a problem, but we can't guarantee that the session won't swap.

We have a single instance of the hibernate session factory within each JVM, and are using caching to prevent excessive hits to the database. The data is too large for the session object, hence the hibernate caching strategy. So each response/request cycle we get the persistent data from hibernate, work on it and persist. The next request doesn't hit the database as the item is cached.

So when it swaps, we can read the data from the database again. No problem as this will now be cached on the other server. But if we swap back to the previous server then our cache will not be in the same state as the database, therefore we need to force a read.

i understand, we have tried similar approach with tomcat 5 and clustering but have encountered the jdbc reconnection problem when the HttpSession (containing an HibernateSession, i know it's ugly but it was just for testing) was balanced.
We had to stop this proto for other projects but if you find a solution for "controlling" cache integrity when session is balanced or for using a distributed cache, it could be great to describe it on a wiki.

Maybe an advanced user or hibernate team member can give you advises

Ok I think I have a solution (I be interested in any comment from the hibernate team).

We will place a transient object in the http session, this will be the indicator as to whether we trust the secondary cache.

If the object is null we know that the session has been serialized and deserialized (indicating that a swap may have occurred - of cource the session may just have been serialized due to memory constraints, but this doesn't really matter).

When the transient indicator is null we will obtain the object from hibernate (which will return a cached copy) and invoke session.refresh(Object) which will force the object to be updated from the database.

Hence we can then ensure that our object is a true reflection of the database, regardless of whether the sesson has been swapped. This does assume that you persist each response/request cycle and therefore the database will always contain the up-to-date object data.

Just to clarify when talking about session in the above comment I mean of cource the http session NOT the hibernate session.