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.<br><br>The pattern would be like:<br>
<br>Updater process:<br> delete from memcache with delete-lock + 5 seconds<br>
delete from masterdb<br><br>Reader process:<br> read from memcache<br> .. miss<br> read from (slave) database<br> find something in the slave (it hasn't got the delete yet)<br> put it in memcache<br> .. but get denied<br>
<br>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.<br>
<br>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.<br>
<br>Or just remove it. I don't think anybody would care.<br><br><br><div class="gmail_quote">On Tue, Jun 24, 2008 at 11:00 PM, dormando <<a href="mailto:dormando@rydia.net">dormando@rydia.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm actually a bit curious on this myself, and believe some of the<br>
development work going on has removed this feature, since it is pretty<br>
awkward.<br>
<br>
We were discussing it in irc and couldn't find a usage pattern that<br>
isn't better off using 'add' with a low timeout. The way it's<br>
implemented is a dynamic array loop thing, which isn't exactly ideal<br>
anymore.<br>
<br>
So, anyone using it? I hope you're listening and speak up soon :) We'll<br>
make a lot more noise as this feature is .. presently slated for removal<br>
I guess.<br>
<font color="#888888"><br>
-Dormando<br>
</font><div><div></div><div class="Wj3C7c"><br>
Wayne Hineman wrote:<br>
> Hi,<br>
> As a newbie to memcached, I've been reading carefully the protocol<br>
> document and have a question about the optional time value on the<br>
> 'delete' command. The document describes very well how it works;<br>
> my question is what is the use case for this function? Is it used<br>
> widely? I can kind of understand a desire to prevent certain keys<br>
> from being stored, but the 'set' command overrides this behavior.<br>
> Is it expected that new keys are always 'add'ed and existing keys<br>
> always 'replace'd? I might expect that the opposite is true: that<br>
> 'set' is used more frequently than add/replace, thus making the<br>
> optional time on 'delete' moot. So what's the thought behind this<br>
> feature?<br>
><br>
> Thanks!<br>
><br>
> Wayne<br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br>