cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Fw: [SourceForge.net Release] ehcache : ehcache
Date Tue, 28 Sep 2004 17:28:21 GMT
Unico Hommes wrote:

> 
> SourceForge.net wrote:
> 
>> Project "ehcache" ('ehcache') has released the new version of package 
>> 'ehcache'.
>>
> 
> I believe this was to be our cue for moving ehcache based store to the 
> core and making it our default right? I have just updated our ehcache to 
> the new release version but haven't yet moved it to the core. If noone 
> objects I will move it to the core later.

One objection - below.


> There still remains one FIXME in the EHCache store implementation 
> though. Method free() hasn't been implemented. AFAIK this one is called 
> by the StoreJanitor to do its work. However, although it works a little 
> different from ours, EHCache has its own kind of janitor mechanism that 
> operates on the basis of time-to-live and time-to-idle expiry 
> strategies. Will this be sufficient or should we try to come up with 
> some sort of implementation of the free() method?

No, it won't be sufficient. Janitor checks that JVM is not starving, and 
cache *must* react on low-memory condition regardless of time-to-live 
and other bells-and-wistles.

In the future Janitor should be hooked into JVM monitoring API:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html

And then the sky is the limit ;-)

Vadim


> Another thing to keep in mind is that EHCacheStore cannot be used in the 
> role of a transient store. This is because it requires entries to be 
> Serializable even if it is configured not to be persistence enabled. I 
> will file an enhancement request to the ehcache guys like we did with 
> JCS at the time, to remove this requirement.
> 
> -- 
> Unico


Mime
View raw message