I have hibernate working in clustered environment with L2 cache enabled (Tangosol Coherence) and two web apps sharing the cache.
I have noticed that every time the objects cached by webApp1 are being read by webApp2, SQL select statements are being issued followed by cache's method put(...) being called. According to this, it seems natural to me to assume that cached objects are being ignored and webApp2 calls DB and then caches the obtained objects again which makes the L2 caching useless.
Is it the expected behaviour and I just misinterpreting log output or it is what I suspect?

seems clustered cache is not activated, may be a setting problem or a cache provider problem.
Try JBossTreeCache

Apparently, it is not the case.
I have checked the cache and found out that a few of the objects (only but not all of read only ones - maybe coincidentally) are being read from cache. When webbApp1 starts using them for the first time, it tries to "get(...)" them from the cache and only then, if they are not there retrieve them from the DB AND then "put(...)" them into cache.
Strangely, Hibernate does not even try to "get(...)" the rest of the objects from the cache, it starts retrieving them from DB straight away and then "put(...)" into the cache.
As I understand, in the situation when the object is created, the expected behaviour algorithm would be something like this:

1)check the cache if the object is there by calling cache.get(...) of the corresponding *Cache class:
1.1a) if it is not, go to DB and retrieve it return the instance to a caller
saving the copy into the cache by calling cache.put(...)
1.1b) if it is there, retrieve it from cache and return to the caller

So, why it does not work this way in my wabApp, did I go wrong with config settings somewhere?
Please enlighten

how are you retrieving your objects? get? load? hql?

Seems like I have figured it out.
It seems that Hibernate tries to get only those objects from L2 cache that have been called by Id e.g. "org.hibernate.Session.classic.get(String entityName, Serializable id)".
when the object is created it is stored into Cache with the following cache key generated:

"[RegionPrefix].package1.package2.MyClassName#MyClass'IdNumber"

I suspect when hibernate is creating a new object it looks into the cache first, trying to find the object with the key with the id concatenated at the end of the object's cache key which is submitted as the parameter to the "org.hibernate.Session.classic.get(String entityName, Serializable id)".
The wrong thing about the objects which I am experiencing problem with is that thay are not being created by the "*.get(...)" method mentioned above but by
*.find(...) method e.g. find(...) which returns a List. So when it tries to get the object not by its id (e.g. dao.getUserByLoginCredentials(String loginname, String password) which wraps find(...) ) Hibernate does not even try to find it in the cache because it does not have Id to concatenate the cache's key string.

So, now my next question is :).... : Is there any way around it?

Please help

query cache or query.iterate()

we really advise you to use query cache ...

Now, when the problem logged above is sorted out (Thank you very much guys for your help), another one came up:


I know that the method "sessionFactory.evict(User.class, user.getId())" works for the objects initialized by get(class, serializable)

What I want to know is what to do in the situation when I want to evict(..) the List stored under the key generated by session.createQuery(...)

Can it be done with Hibernate API?

Hi Vlad,

As far as I can tell, Hibernate does not include an API for evicting specific query results, meaning that you're best off specifying the eviction settings in the underlying Query Cache configuration (coherence-cache-config.xml or equivalent).

If you need to programmatically evict, there are a number of possible work-arounds, including going directly to the underlying query cache (from the cache provider) to evict, or clearing the entire query cache. The former bypasses the Hibernate API (creating a maintenance issue), and the latter is obviously not very efficient if you need to evict regularly.

Depending on the number of cached queries, you may be able to set up a cache region per query (which I believe will create a single Coherence NamedCache per query), meaning that clearing the cache will be equivalent to evicting the specified query. The overhead in terms of CPU and memory for doing this is minor, though possibly significant compared to the cost of the query that you're trying to cache. If you can use this pattern with groups of queries it will at least spread out the overhead.

I'm curious to see if others can recommend a more efficient approach ...