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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
>
>
>
>
