Another Delete Question...
brad at danga.com
Thu Jun 26 01:48:05 UTC 2008
So, the original motivation iirc was for people to be able to a little more
safely populate memcache (with "add") when reading from an asynchronously
replicated slave database.
The pattern would be like:
delete from memcache with delete-lock + 5 seconds
delete from masterdb
read from memcache
read from (slave) database
find something in the slave (it hasn't got the delete yet)
put it in memcache
.. but get denied
In practice, though, it's a lame strategy. You don't know at delete time
how far behind your slaves "should" be. And you should never update your
memcached sourced from an inconsistent replica.
In my recent memcache hacking I implemented this feature not as memcached.cc
does (with the delete queue and timers and such) but rather just reusing the
expiration time field to then mean the "delete locked until" field, and
using a different internal flags. You might want to take that approach to
remove some complexity while remaining compatible with the docs.
Or just remove it. I don't think anybody would care.
On Tue, Jun 24, 2008 at 11:00 PM, dormando <dormando at rydia.net> wrote:
> I'm actually a bit curious on this myself, and believe some of the
> development work going on has removed this feature, since it is pretty
> We were discussing it in irc and couldn't find a usage pattern that
> isn't better off using 'add' with a low timeout. The way it's
> implemented is a dynamic array loop thing, which isn't exactly ideal
> So, anyone using it? I hope you're listening and speak up soon :) We'll
> make a lot more noise as this feature is .. presently slated for removal
> I guess.
> Wayne Hineman wrote:
> > Hi,
> > As a newbie to memcached, I've been reading carefully the protocol
> > document and have a question about the optional time value on the
> > 'delete' command. The document describes very well how it works;
> > my question is what is the use case for this function? Is it used
> > widely? I can kind of understand a desire to prevent certain keys
> > from being stored, but the 'set' command overrides this behavior.
> > Is it expected that new keys are always 'add'ed and existing keys
> > always 'replace'd? I might expect that the opposite is true: that
> > 'set' is used more frequently than add/replace, thus making the
> > optional time on 'delete' moot. So what's the thought behind this
> > feature?
> > Thanks!
> > Wayne
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached