Re: POJO caching in geronimo

Hello, Gianny Damour and team. I want to list my questions and proposals to the possible architecture and features of the Geronimo POJO cache that WADI is going to implement soon.

Assume that we are exposing a POJO cache using GBean, so POJOCache is available through JNDI (new InitialContext().lookup("java:comp/env/cache")) if gbean-ref and dependencies is included into Geronimo specific deployment plan.  The following questions are interesting for me.

1)     I wonder what interfaces need to be exposed to access this POJO Cache. We need to list these interfaces in "implements …" block when declaring GBEAN and in gbean-ref / ref-type section. And developers will use the pojo cache using these (this) interface as well.

I suspect that we need at least the following interfaces: JSR-107 JCache related interfaces, plain java.util.Map, and the specific implementation (ehcache, jcs) if someone needs to use that implementation directly.

First of all I want to consider JCache. JCache standard is far from being a final and it is changing till now.  Here is the list of limitation of the current JSR standard http://ehcache.sourceforge.net/documentation/jsr107.html (see section "Problem and limitation"), so these limitations need to be worked around or just emphasized for the developer if we decided to expose JCache as the primary interface over geronimo pojo cache gbean.

The next question is on plain java.util.Map interface. In theory JCache (JCache.CacheMap) implements Map, so one may do the cast "(Map) jcache" if (s)he prefers plain Map over instantiating JCache or just uses Map in  code already.  However http://shevek.livejournal.com/84313.html complains on a slight incompatibility with the expected usage of Map, so  our pojo gbean might  play as wrapper to resolve this incompatibility as well.

The last issue on getting underline implementation can probably be easily solved with gettingBackingCache() method from JCache, although it quite interesting to figure out (from configuration or JMX) which implementation is tired with now.

2)     The next question is on the number of GBean, that related to the maintenance of pojo caching. Is the PojoCache gbean needs to be the only gbean related to the cache, or (in distributed case) it may act as wrapper to the actual ehcache/tabgosol/terracotta/wadi/jboss-cache-wrapper gbeans. In the later case we just need to raise up the target  gbean and provide all configuration to it, and later just wired the actual GBEAN with the remote (external) one. This may probably help to monitor and configure these caches in more subtle way and allow to remain everything in the target application the same (even a Geronimo-deployment descriptors), while just plug-in (hot-replace) any remote / distributed / multilayered caching solution even in runtime. Example, you just set up the application (war/ear) that have the only dependency o local POJO cache gbean, that is used fast JCS back end while no other authentificated plug-in discovering request occurs, but when this happens your caching solution becomes multi tired (hierarchical) with very light 1level local cache with specific expiration policy and 2level distributed (memcache-d aware) cache.

3)     The third question is on Statistic. We have some pretty tab on the JMX section in Geronimo that seems to be used as viewer some graphics on historical data. Really I don't know how to exposed some data from the Gbean to there, but it seems to be nice to have exposed such a parameters as number of hits per second, or the pluggable one statistic like "how many request in percent to the total are done to the specific part of our cached data" or "how many data are stored in the disk sue to short overflow of overall memory restriction for the given local cache" (when storing is switch on). The result of such a statistic is useful for capacity planning and tuning the system.

It's interesting not only to plug such a statistic and get this from regular Geronimo JMX tabs, but do this easily with no binding to the specific underline implementation. I suppose that this may be done if we just wrap any put / get methods of POJO GBean implements JCache with some JAMON  (*). Concrete interceptors (what collect in very specific cases) may be tired up  with GBean using AOP (**). Probably we need to integrate native JMX support for  such a project as well (***)

So we have three questions here: how to expose such a data to JMX statistic tab, how to add user defined interceptors, and how to configure (switch off such a tools on production when deploy or in runtime by JMX value)

4)     The next question is where to locate specific configuration files like ehcache.xml. The more precise question is where it is possible and appropriate to locate such a files. I suppose that local cache parameters (1level local cache gbean) may be located in war/ear, and the parameters for regular distributed cache (2level distributed cache gbean) needs to be located in config.xml  + var/config

5)     The last issue is to provide compact maven build  and maven subproject to easily install specific cache bundle (with no 70 mb of terracota, the WHOLE wadi or something else)

6) What do we  need to get reasonable  from http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/2.2.0.BETA1/userguide_en/html_single/index.html or Glassfish cashing?

 

 
(*) www.jamonapi.com

(**)http://www.ibm.com/developerworks/java/library/j-aopwork10/

(***)http://wiki.burnayev.com/page/JMX+Monitoring+of+Ehcache?t=anon

 

 What do you think on this?

    

--
Best regards,
~ Xasima Xirohata ~