Looks good. Certainly an improvement There is anoter thing I have been thinking about. It is not directly related to the proposal, but more to caching in general. I wonder what other people think about it. How about a caching chain (for the queries) where a cache descides if it handles the request or passes it on? What I would like to see is that you can for instance have different caching for some part of your cloud in a configurable way. So if you fire a query, it goes into the chain, where the caches one by one evaluate the query and based on it handle the query (pull from cache or run query on db), or pass it up. That way the query should allways be cached in the most opportune way.
What makes me think this way is the fact that for instance data trees (like for a) are not cached well by the multilevel cache. You could write a cache that checks if a query is for some part of the cloud, and then process it in a special way. If not, it passes it up (to the multilevel cache...) I would like to know what people think about it.. Ernst > -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Namens Michiel Meeuwissen > Verzonden: dinsdag 19 oktober 2004 22:51 > Aan: [EMAIL PROTECTED] > Onderwerp: Pluggable cache-implementation. > > > > Locally, I have changed 'Cache.java' and 'LRUHashtable.java' a bit. > > The goal was to make the 'implementation' of the cache pluggable. > > Like this: > > - Cache does not any more extend LRUHashtable (but > AbstractMap), and wrappes an object of the type > 'CacheImplementationInterface': > public interface CacheImplementationInterface extends Map { > > /** > * Sets the (maximal) size of the cache (if implementable). > */ > void setSize(int size); > > /** > * Gets the (maximal) size of the cache (if implementable) > */ > int getSize(); > > /** > * Returns the hit-count on a certain key (if implementable). > */ > int getCount(Object key); > > } > > > - LRUHashtable implements that. > > - I moved getHits, getPuts, getMisses, getRatio kind of > functions to Cache.java and also implement > those there. LRUHashtable gets cleaner, because it > implements only its essence. The idea is that > every cache, independently of its precise implementation > should and could have those, so Cache > can easily implement that itself. > > This is not completely backwards compatible, because people > could have instantiated LRUHashtable > and used those methods (I saw in vpro code that they do). > > Optimization project has proposed to move LRUHashtable to > cache package (I'd propose > org.mmbase.cache.implementations then). If we do so, > current users will any how need to > recompile. They could e.g. replace new > org.mmbase.util.LRUHashtable() by new > org.mmbase.cache.Cache() to fix it. > > > - In caches.xml you can have an extra tag '<implementation>' > which defaults to LRUHashtable. > But other implementation become possible. I saw e.g. an > implementation (also at vpro) of a 'timed' > cache. > > > - The methods of CacheImplementationInterface seem optional, > because I can imagine caches for which > those methods don't make sense. Perhaps it can be > implemented that a Cache implementation may > simply be any Map implementation (if necessary with a > specialized CacheImplementationInterface > implemenation..) > > > The changes are relevant for the optimization project, and > perhaps especially for the performance part of it. > > I'm not sure what problem this change would immediately > solve, but the change is actually quit small and > straigt-forward, and I suppose that the possibility to plug > in differnt cache-implementations can become important. E.g. > a cache implementation which invalidate entries after a > certain time, a cache implementation which is more reluctant > to invalidate query results which took a long time to > produce, a cache implementation which can detect that Queries > are somehow marked as 'shortly lived' (embargos!), and would > not or only shortly cache those. Anyhow the possibilities > seem endless! > > How do you feel about it? Could I offer this as a HACK? > > > Michiel > > -- > Michiel Meeuwissen mihxil' > Mediacentrum 140 H'sum [] () > +31 (0)35 6772979 nl_NL eo_XX en_US > > > > >
