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. ;-)
Best Regards,
Antonio Gallardo.
[1] http://jakarta.apache.org/jcs/JCSvsEHCache.html
