<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><BR class="khtml-block-placeholder"></DIV><DIV>[replying back on the list to try to keep the discussion open and hopefully avoid repeating myself]</DIV><BR><DIV><DIV>On Sep 8, 2007, at 7:31, Jehiah Czebotar wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">This sounds like the proposed "append" method which would allow</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">memcache to handle lists on the server side... with one caviat, you</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">want a conditional append which only appends if the value isn't</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">already there.</FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>In this example usage...sort of.� One would also want to remove items from the list to keep it from growing out of control.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>There was another proposal to allow updating parts of a value by offset or other such things.� None of these things can work race-free without implementing advisory locks which, as already pointed out, may be subject to the LRU.</DIV><BR><BLOCKQUOTE type="cite"> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">If memcached were handling the lists, you wouldn't have to add all</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">that conditional logic and "replace if it's still the same" stuff</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">which won't work in high concurrency situations anyway.</FONT></P> </BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Well, it's not entirely fair to say it doesn't work in high concurrency situations.� The operation is always atomic, but it may need to be retried.� This is a common strategy in concurrent programming for creating lock-free concurrent data structures.� If a particular key is too hot, though, you could potentially split it into multiple keys to reduce retries in practice.� In the current example, you could have a series of current_login keys hashed by uid.� Your contention is reduced by the number of keys.� There's never a case where you blindly overwrite values, though.</DIV><BR><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Adding an add-this-to-a-list-if-it-does-not-exist-and-remove-something-else-to-keep-the-list-to-n-elements would be an unreasonable operation to add.� The only reasonable way to do something like this would be to add server-side scripting and then effectively write the exact operations you need so that they may be performed atomically.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Are there enough potential server-side operations to really justify a scripting interface?� When it's been brought up in meetings, the response has varied from interest, to a warning about crossing streams or something.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>Both a CAS and a scripting interface provide a foundation for building atomic data structure manipulation without having to define all of the data structures and all of the operations at the protocol level.� Each has downside.� With CAS, you may have to retry a few times under contention and this would be amplified by the latency.� With scripting, you may easily slow down the whole server, and you have to deal with how parameters are passed in and results are returned -- and this would mean very different things by protocol.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>--�</DIV><DIV>Dustin</DIV></BODY></HTML>