As some of you (the
JavaZone participants) may already know, on
InfoQ we are using both
Jackrabbit JCR implementation and
Hibernate for persistence (we are trying to put the data where it belongs [smile/]).
As always Hibernate is doing a great job and I am very happy with it. We have enabled second level cache and also the query cache (using
EHCache because due to our architecture we don't need clusted caching) and the performance we get is really cool. However, lately one of my collegues has pointed me that something weird is happening: a stored entity which should be refreshed only after X hours, is getting refreshed much more often. Now, I thought this is really weird. Even worse, this is happening only in some very specific scenarios. So, I started to look into the problem.
The cache configuration is correct as everywhere else I see the expected behavior and the code snippet I've identified as being the cause of the problem is classical:
return session.createCriteria(CategoryDef.class)
.add(Expression.eq("alias", alias))
.setCacheable(true)
.setCacheRegion("CategoryDef.QueryCacheFindByAlias");
So what's going on?
The secret of the problem I was looking into is that the cache region
CategoryDef.QueryCacheFindByAlias was missing from the
ehcache.xml (the special EHCache configuration file). Because of this, once this region/cache should have been used, a new cache with the specified name was created... based on the properties of the
defaultCache.
The tricky part was that I would have expected that the new cache to be created using the
org.hibernate.cache.StandardQueryCache (the query cache), but my initial thoughts were definitely wrong, this region being used only for the unnamed/anonymous cached queries, all others being considered normal cache regions. The way I figured it out was even more interesting: doing a debug session I have noticed that in case of a cache miss, the query went to DB and retrieved the whole entities without checking the second level cache (still it is checking against the current
Session cache). And this was the point that made me think that in fact I am looking at a normal region (derived from the default) and not to a special one. To confirm my supposition, I have checked the
Cache configuration and indeed the parameters were the ones defined into the
defaultCache.
