[PATCH] Sending remaining TTL in "read"'s response
dustin at spy.net
Fri Dec 7 16:58:43 UTC 2007
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
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 <dormando at rydia.net> wrote:
> Dustin Sallings wrote:
>> On Dec 6, 2007, at 19:03, dormando wrote:
>>> - We discussed the alternative method of wrapping the real
>>> 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
>> 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
> its own.
> What're some problems this could help resoundly solve? My lack of
> creativity is embarassing.
More information about the memcached