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
