Another Delete Question...
dormando
dormando at rydia.net
Thu Jun 26 15:49:02 UTC 2008
I think we'll slate it for removal, but change the implementation if
someone speaks up during the -rc process. This feature confuses a lot of
people already.
Thanks though, I couldn't find the original mails :)
Brad Fitzpatrick wrote:
> 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:
>
> Updater process:
> delete from memcache with delete-lock + 5 seconds
> delete from masterdb
>
> Reader process:
> read from memcache
> .. miss
> 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
> <mailto: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
> awkward.
>
> 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
> anymore.
>
> 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.
>
> -Dormando
>
> 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
> >
> >
> >
> >
>
>
More information about the memcached
mailing list