cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <>
Subject RE: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys
Date Wed, 26 Jul 2006 10:35:49 GMT

> Ard Schrijvers escribió:
> > </snip>
> >   
> >> If there are better alternatives to ehcache we should 
> consider them of
> >> course. Personally I would like that this work will be 
> done in trunk
> >> only. We could build an own maven project for each cache 
> >> implementation
> >> which will reduce the dependencies for a user and makes
> >> switching/choosing fairly easy.
> >>
> >> But if we provide alternatives we should have at least 
> some guidelines
> >> explaining when to choose which implementation.
> >>     
> >
> > I will try to see if whirlycache meets our goals better 
> (especially I want to look at the way the diskStore behaves 
> (I want to be able to limit the diskStore keys), and wether 
> we can access the eviction policy from within our classes, to 
> be able to free some memory from cache in a sensible way). I 
> think those guidelines should be in the document I am 
> planning (sry...still in planning phase) to write on caching 
> and best practices. Also the many store configurations, in 
> which errors are easily made should be (will be I hope) 
> documented transparently. 
> >   
>  From your provided link [1], the last section said:
> "JCS limits the number of keys that can be kept for the disk 
> cache. EH 
> cannot do this."
> > I am not sure if supporting many cache implementation is 
> good practice. If there is a large difference between the 
> caches, where cache1 performs much better in memoryStore, and 
> cache2 much better in diskStore, and cache3 is avergae in 
> both, then I suppose supporting different caches might be a 
> good option (though, an easy lookup of which cache impl suits 
> your app best should be available. Then again, this 
> documentation ofcourse is outdated after every cache impl release)
> >   
> Dunno too, but from a practicl POV, supporting different caches would 
> make easier to use the same cache in combination with other 
> libraries. 
> ie: Apache ojb or hibernate. For this reason, I am +1 to support 
> different caches. ;-)

Ok, by me. As long as people know/can find out easily, which one to use. Furthermore I saw
there is a cocoon howto for the whirlycache [1] (Eric Meyer implemented this one). Though,
the things I was looking for in whirlycache are not implemented in the WhirlycacheStore, which
implements the excalibur store [2].

Current shortcomings are:

1)boolean containsKey(java.lang.Object key) is not implemented: is says "I can't imagine why
anybody would rely on this method.". Probably they do not think anybody ever wants to use
this one, though I quite frequently use it. I use it when I am not interested in the cached
reponse, but only wether the cachekey is present. Why would you ever need that? : when you
use event caching it is often enough to know wether the cachekey exists.
2) java.util.Enumeration Keys() says: "we don't support keys". Our StatusGenerator relies
on it, and looking at a sites cachekeys in a Status overview is the very first thing I do
when sites are having problems. A lot can be seen in cachekeys, also implementation errors
and flaws (like repo uris that cannot invalidate, search query results that are cached, and
time/date things in cache keys)
3) void free() says: "This method is not supported by WhirlyCache". This one makes our StoreJanitor
totally useless in trying to free some cache when low on JVM.

I haven't checked out the code yet, so am not sure wether it is easy to implement number 1,2
and 3. If it is not possible, I think I will stick to ehcache or JCS. For whirlycache I still
have to check wether the removing keys according the eviction policy from the outside is possible.

I have one last remark/question that I am really curious about: In all cache implementations
(ehcache, JCS, wirlycache), I haven't found one single cache having public methods to easily
"manually" move cachekeys from memoryStore to diskStore according the eviction policy, delete
number X memoryStore cachekeys+response and also for diskStore. Without these methods, there
is no single way we can have a real proper working StoreJanitor. 

Do you think there is a specific reason why the implementations don't facilitate these quite
simple (and in my opinion important) methods? Is it very strange to have this requirement?
The JCS developers said it shouldn't be that hard to implement it in JCS. I will try if whirlycache
makes it easy to implement these requirements

Regards Ard


> Best Regards,
> Antonio Gallardo.
> [1]
> >   

View raw message