[PATCH] Sending remaining TTL in "read"'s response
nick at reloco.com.ar
Sun Dec 9 23:10:09 UTC 2007
>> Having the expiry time returned explicitly instead of part of the data
>> does make things slightly easier, but otherwise isn't much of an advantage.
> I was advocating that point actually ;) What I'm curious about was
> Dustin's idea of having a stream of expiration data that a service could
> subscribe to.
I guess the utility is to be able to have consistent L2 caches. So that
an L2 cache would be able to drop its value if somebody has
incremented/deleted/etc it. My "send the remaining TTL" patch only
handles the expration case, having some kind of notification would
handle every case.
A needs "key1", gets it from memcached, caches it locally. Register for
A needs "key1", it's locally cached, no memcached access.
B increments "key1", invalidation notifications get sent. A invalidates
its local cache.
A needs "key1", gets the new value from memcached.
I don't know how useful this would be, but I think this is what is being
talked about, I think.... =)
More information about the memcached