On 8/17/07, <b class="gmail_sendername">Evan Miller</b> <<a href="mailto:emiller@imvu.com">emiller@imvu.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Wraparound might actually be a better solution for you, because it<br>solves the concurrency problems. Currently, several clients that<br>simultaneously attempt to increment past the size limit will all receive<br>errors, and they will all attempt to run your reset logic. I don't know
<br>about your specific use-case, but for us this means that increments get<br>lost in the meantime (multiple clients reset the counter to 1).</blockquote><div><br>Hmm... I hadn't thought of it that way. I only have one piece of code right now that could possibly hit the wrap-around effect, and I have it locked so that only one client can perform a replenishment operation. This is triggered whenever it receives an error from the client.
<br><br>Now that I think about it more, its not such a big deal to me either way, as I can easily detect either condition. I'm currently used to dealing with objects that fail rather than wrap-around, so I couldn't grasp why you would want it to, but what you say does make sense.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">With wraparound, only one client will receive a "0" return value, and so
<br>only one client will run the additional reset logic.<br><br>It's true that clients which rely on the increment errors will need<br>tweaking, but overall wraparound makes Memcached more useful and robust<br>as a generic counter service.
<br><br>It would be even more useful if calling "incr" on a non-existent key set<br>the value to "1" in order to avoid race conditions similar to what I<br>describe above, but that's a different can of worms...
</blockquote><div><br>Yes, that would actually cause me some trouble... <br></div>I currently rely on "incr" failing if you try to incr a key that doesn't exist.<br><br></div>I'm one of those zealots that litters their code with asserts to ensure that any loss of integrity on data is readily identified. As a result, I'd rather know if something failed, rather than get some default value that just might allow the code to work, but not be correct.
<br><br><br>