</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. 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) I hope to see one cache being superior in every facet. That would make choices easiest. Regards Ard > > > Carsten > -- > Carsten Ziegeler - Open Source Group, S&N AG > http://www.s-und-n.de > http://www.osoco.org/weblogs/rael/ >
