So, the original motivation iirc was for people to be able to a little more safely populate memcache (with &quot;add&quot;) when reading from an asynchronously replicated slave database.<br><br>The pattern would be like:<br>
<br>Updater process:<br>&nbsp; delete from memcache with delete-lock + 5 seconds<br>&nbsp;
delete from masterdb<br><br>Reader process:<br>&nbsp; read from memcache<br>&nbsp;&nbsp;&nbsp; .. miss<br>&nbsp; read from (slave) database<br>&nbsp; find something in the slave (it hasn&#39;t got the delete yet)<br>&nbsp; put it in memcache<br>&nbsp;&nbsp;&nbsp; .. but get denied<br>
<br>In practice, though, it&#39;s a lame strategy.&nbsp; You don&#39;t know at delete time how far behind your slaves &quot;should&quot; be.&nbsp; 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 &quot;delete locked until&quot; field, and using a different internal flags.&nbsp; You might want to take that approach to remove some complexity while remaining compatible with the docs.<br>
<br>Or just remove it.&nbsp; I don&#39;t think anybody would care.<br><br><br><div class="gmail_quote">On Tue, Jun 24, 2008 at 11:00 PM, dormando &lt;<a href="mailto:dormando@rydia.net">dormando@rydia.net</a>&gt; 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&#39;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&#39;t find a usage pattern that<br>
isn&#39;t better off using &#39;add&#39; with a low timeout. The way it&#39;s<br>
implemented is a dynamic array loop thing, which isn&#39;t exactly ideal<br>
anymore.<br>
<br>
So, anyone using it? I hope you&#39;re listening and speak up soon :) We&#39;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>
&gt; Hi,<br>
&gt; As a newbie to memcached, I&#39;ve been reading carefully the protocol<br>
&gt; document and have a question about the optional time value on the<br>
&gt; &#39;delete&#39; command. The document describes very well how it works;<br>
&gt; my question is what is the use case for this function? Is it used<br>
&gt; widely? I can kind of understand a desire to prevent certain keys<br>
&gt; from being stored, but the &#39;set&#39; command overrides this behavior.<br>
&gt; Is it expected that new keys are always &#39;add&#39;ed and existing keys<br>
&gt; always &#39;replace&#39;d? I might expect that the opposite is true: that<br>
&gt; &#39;set&#39; is used more frequently than add/replace, thus making the<br>
&gt; optional time on &#39;delete&#39; moot. So what&#39;s the thought behind this<br>
&gt; feature?<br>
&gt;<br>
&gt; Thanks!<br>
&gt;<br>
&gt; Wayne<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
</div></div></blockquote></div><br>