The basic idea is to be able to have your l2 cache know when to
discard something. Currently, that means knowing one of the following
things occurred:
1) cache expired
2) lru removed item
3) item was explicitly deleted
4) item was replaced with set/replace/cas
5) item was updates with incr/append
Additionally, you'd probably also want to know about a flush.
You could build a secondary cache based only on tracking
expirations, but it would give wrong answers for many valid use
cases. For example, the "I'm going to cache this for a really long
time and update it in-place when I know it's changes" case.
--
Dustin Sallings (mobile)
On Dec 6, 2007, at 21:37, dormando <[EMAIL PROTECTED]> wrote:
Dustin Sallings wrote:
On Dec 6, 2007, at 19:03, dormando wrote:
- We discussed the alternative method of wrapping the real
expiration
time inside your serialized object, and using that instead. We think
that works out better for all invovled :)
The thing I've mentioned a couple of times, but have put no effort
into whatsoever is the ability to subscribe to an invalidation stream
somehow. It'd be pretty awesome to simply be notified when things
happen that invalidate keys.
There are obviously a few large holes that come about when one
goes
to implement such an idea (it shouldn't weigh down mutations, and
there's the question of how to be notified when something just
expires). I suppose the expiration time could be skipped if the
second-level cache *also* tracked the times.
It'd be a hard thing to get right, but it's the right way to do a
second-level cache.
Trying to think of how to use this... If something's expired in my
cache, there're good odds it'll be requested in that same second, or
very nearterm. It's more efficient to just let it expire and recache
on
its own.
What're some problems this could help resoundly solve? My lack of
creativity is embarassing.
-Dormando
