geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xasima Xirohata" <xas...@gmail.com>
Subject Re: POJO caching in geronimo
Date Wed, 14 May 2008 21:20:54 GMT
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.htmlor
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?




On Thu, May 1, 2008 at 6:22 AM, Gianny Damour <gianny.damour@optusnet.com.au>
wrote:

> Hello Xasima,
>
> WADI does not yet provide a POJO caching solution.
>
> Regarding the http://incubator.apache.org/wadi/wadi-core/apidocs/org/codehaus/wadi/gridstate/impl/GCache.html
> class, AFAIK it was more an idea than an actual fully working caching
> implementation.
>
> I know that a Geronimo POJO caching solution, GCache, was implemented a
> while back in the geronimo-sandbox and documented here http://
> cwiki.apache.org/GMOxDEV/geronimo-clustering-with-gcache.html. However, as
> this caching solution has not been touched for a while, I do not think it is
> in a working state.
>
> The approach you are taking seems to me reasonable and I think it would be
> quite useful for other users to have such GBean services for JCS or EHCache.
>
> FYI, I am currently working on the implementation of a hierarchical,
> transactional, distributed, partitioned and replicated cache and data-grid
> solution as part of WADI. I hope to have a working solution at the end of
> the month and hopefully before you having the need for it :)
>
> Thanks,
> Gianny
>
>
> On 01/05/2008, at 2:22 AM, Xasima Xirohata wrote:
>
>  Hi. I want to figure out what is the proper strategy to plug-in POJO cache
>> into geronimo (2.1).
>> I want to use the different implementation of caching (HashMap,  EHCACHE,
>> JCS) and work in standalone mode  (not explicit clustering support for the
>> first time).
>>
>> In the existed code we just want to get a cache instance using JNDI, cast
>> this to java.util.Map and  invoke plain put/get methods.
>> I have explored geronimo docs and found the following possibilities:
>>    1) use the terracotta (http://www.terracotta.org/confluence/display/orgsite/Distributed+Caches)
>> that exposes such an wrapper around different implementation.
>>    2) use the wadi and the http://incubator.apache.org/wadi/wadi-core/apidocs/org/codehaus/wadi/gridstate/impl/GCache.html
>> class somehow
>>    3) use the custom gbean as wrapper upon different implementation of
>> caching (as the general solution for any separate custom services).
>>
>> Unfortunately, the 70Mb size of Terracotta seems too heavy to use for such
>> a use case when I don't plan to work with clustering at once.
>> I don't found a page to integrate this options with WADI, please provide
>> some details on this..
>> So I have stopped with the last way. I think that having POJO cache
>> exposed as gbean (instead of using as regular embedded jar) is a right
>> strategy since it is quite naturally to
>>    1) implement initializing, clearing, storing (if persistence is on) of
>> POJO cache when the correspondent geronimo lifecycle events occur
>>    2) providing different <attribute > </attribute> in the gbean plan
to
>> configure in external manner different  POJO cache parameters
>>    3) having MBean that reports on state and loads of the cache ( it may
>> be interesting how  much objects are consumes from this and if we need to
>> change expiration policy or allocate more size)
>>
>> Am I right with the approach? Do you have any predefined gbeans (or
>> prototype in sandbox code area) code for this?
>> Could I use WADI for this purpose?
>> --
>> Best regards,
>> ~ Xasima Xirohata ~
>>
>
>


-- 
Best regards,
~ Xasima Xirohata ~

Mime
View raw message