Another Delete Question...

[dormando]

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