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 18:00:39 GMT
Unico Hommes wrote:

> Vadim Gritsenko wrote:
> 
>> Unico Hommes wrote:
>>
>>> 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.
>
> 
> Then what about implementing free() so that it removes a specified 
> number of elements? Perhaps there is a possibility to find out the LRU 
> ones. I believe StoreJanitor tries to free memory until the low-memory 
> condition goes away, so such an implementation would suffice right?

free() should free up just one element from the cache. Ideally, it 
should be LRU or just-to-be-expired (it should keep list of expiration 
times, right?) cache element. Janitor will take care about freeing up as 
much elements as necessary (from all registered caches).

See [1] for reference free() implementation ;-)

Vadim

[1] 
http://svn.apache.org/repos/asf/excalibur/trunk/components/store/src/java/org/apache/excalibur/store/impl/MRUMemoryStore.java

Mime
View raw message