sorry for the long explanation, but I wanted to make things clear.
I am a LAMS developer. Till now, we were using JBoss Cache 1.4.2 on JBoss 4.0.2. It was deployed as a MBean and was made available by JMX as "jboss.cache:service=TreeCache".
The new idea was to use the latest JBoss Cache 3.1.0.
and we only have one, local instance of Cache.
The suggested way of deploying Cache is to use "-jboss-beans.xml"
For our needs, "lams-cache-jboss-beans.xml" was written.
But there is problem with Hibernate 3.3 integration. I want to use SharedJBossCacheRegionFactory. It looks for the Cache config file (treecache.xml) and builds its own instance.
But in LAMS we need access to cache from withing the code too. We have a special website for Admins where they can lookup and manipulate the cache.
So we need a separately deployed Cache instance, like the way we did before.
CacheFactory and we have only the interface, which can not be exposed.
Then, there is CacheJmxWrapper class. It wraps the Cache and allows JMX exposition.
we have it only in JMX. So we need to expose it to JNDI.
Standard <jndi-name> tag does not work - parser will not read it.
It gets the cache from JMX and exposes it to JNDI.
Cache itself! For our Admin code it is OK, but for Hibernate it's not. It would not accept the exposed bean.
The question is: is there a way to expose the Cache itself to JNDI, to make Hibernate accept it and also get it for Admin?
Currently SharedJBossCacheRegionFactory is used and a local instance of Cache is created. It is not exposed to JMX, so we do not have access to it from within the code.
until a way to utilise lams-cache-jboss-beans.xml is found.
No answer ever came, so I reply to myself.
For upcoming LAMS release, we are using pretty much the same version of JBoss as 3 years ago, JBoss 5.1.0.
This means that no new tools are available in JBoss to solve cache access problem.
After extensive search, no solution to expose same Cache instance both to Hibernate and CacheManager using JMX/JNDI was found.
This may be possible after upgrade to newer major JBoss version, but for LAMS 2.4 another solution was needed.
CacheManager gets now Hibernate SessionFactory injected by Spring. This way it can in limited manner manipulate 2nd level cache.
Very frustrating, but this was the best we could do with given tools.
I've just made a comment in that link, but essentially, it should be Hibernate who, independent of the cache provider, should provide such API to clear all caches in a session factory. I've opened a dev discussion in the Hibernate mailing list.
Btw, there's new API in Hibernate that allows evicting all entity, collection and query regions, see http://java.dzone.com/tips/clearing-hibernate-second-leve where Steve Ebersole, Hibernate lead, has commented further.
At the moment we are using Hibernate 3.2 and the new methods are available in 3.5. We are not planning an upgrade for our upcoming product release, so we'll just stick to the existing solution.
Nevertheless, we might just use this information in the future.