Magnús ?ór Torfason wrote:
> What you propose seems perfect for Turbine. I have one thought
> about the wrapper class (in turbine it is CachedObject). I like
> the fact that in the current Turbine Cache it is the object itself that
> determines if it is stale, and the RefreshableCachedObject
> class seems very useful to me. This has pros and cons, of course.
>
> It implies that the algorithm for determining staleness
> is implemented in the wrapper class, so the Cache itself
> cannot select a specific algorithm (since it may contain
> many types of wrappers).
>
> Instead it would be possible to specify a default wrapper
> class for a given Cache. Objects could then be added
> directly to the Cache, using the default wrapper, or
> wrapped outside the cache, and added all wrapped and ready.
In our LRU cache, the algorithm for determinig which object should
be removed from the cache is contained in the Cache implementaion
class itself. The wrapper contains only an Object reference and
a timestamp that is set to current system time whenever wrapper
object is constructed or getValue()/putValue() methods are used.
A cache that stores object that can expire over time will probably
gain more from imposing requirement on the type of stored object
to be an interface that has methods for determining object's
staleness. Using a wrapper class with timestamps doesn't really
allow the Cache implementation to track the moments when the
internal state of the cached object changes, extending its validity
period.
We should look closely into any posibility of enhanced code reuse,
and flexibility, but right now I don't see any benefits of making
the wrapper class generic/pluggable.
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
