[PATCH] Sending remaining TTL in "read"'s response

Dustin Sallings 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  
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 <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  
>>> 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
>
>


More information about the memcached mailing list