Right, Thanks for clarifying and reaffirming my thoughts on how CAS is used. Also appreciate pointing out that error codes exist in Memcache. We use clients (Python Memcached) that mask these errors, so never knew these existed.
I have seen CAS getting done as a re-try mechanism in a code and was wondering if it might just work as a side effect in this scenario: memcache.cas(key, value), the CAS failed because of server load(?), client indicated a failure, and the programmer started using this side effect. The CAS might have failed due to a dirty state too, but the programmer kept on retrying until it effectively set of the new value. You get my point? The programmer achieved his goal which actually was not really intended and was a side effect due to his client. I know it depends on the clients. That also leads to me one extra question would memcache.cas and memcache.add fails because of server load or is it only memcache.set that has this problem? I believe I need to really start dealing with error codes to solve my problem with memcache (which is a weird kind of lock thing) and possibly use a different tool though memcache does achieve a good 99% success ratio. Thanks in advance for your help. On Friday, June 24, 2016 at 8:59:00 PM UTC+5:30, Colin Pitrat wrote: > > The usage is the same whethere your data is a simple counter or a complex > structure serialized. > CAS allows you to ensure that the value didn't change between the read and > the update that follows it. > The idea is that if it fails, it means someone else updated the value in > between and therefore you need to re-read it, redo your process and redo > the CAS. > > If you do a set and it fails, I don't see why you would make a CAS after > that. > I see 4 options that make sense in my opinion: > - retrying the set (but beware of adding more load in case the first set > failed because the server is overloaded) > - failing the transaction (e.g: returning an error to the user doing the > action) > - doing a delete on the key (to remove a now outdated value) but if the > update fail it will probably fail, unless the issue was with the value you > tried to set > - ignoring the error > A possibility is to take a different action depending on the error you get. > > What you can do is make a CAS after a failing add, because if you read the > value, it was missing and the add fails (with the "already exist" error > code) it means the key was set in the meantime. > So you can read the value and make a cas to update it. > > Hope it helps > > 2016-06-24 14:12 GMT+01:00 Nishant Varma <tnis...@zeomega.com > <javascript:>>: > >> http://neopythonic.blogspot.in/2011/08/compare-and-set-in-memcache.html, >> GVR talks about a use case of a simple counter. >> >> Generalizing that, 1) would it be fine to say you could use CAS when you >> need to modifying the data according to the latest state? For example >> counter, appending a list, modifying a dictionary etc ..? >> >> 3) I could *retry* memcache.cas(key, value) where value is a static >> data, but I think it doesn't serve any more purpose than memcache.set(key, >> value) right? >> >> I have seen some snippets that try to overcome memcache.set misses by >> implementing a memcache.cas. It sounds logical because it is done in a >> *retry* but what is not logical is that it *fails* if the value has >> *changed* already and not if a *miss* happened, am I right? >> >> 4) However I wonder if it is possible to use memcache.cas for overcoming >> set misses as a side effect? A miss happened, client returned a failure, >> retry happened it worked. >> >> And I wonder 5) if there is a better way to handle set failures 6) does >> memcache.add also have set failure possibilities. >> >> This e-mail message (including any attachments) may contain information >> that is confidential, protected by the attorney-client or other applicable >> privileges, or otherwise comprising non-public information. This message is >> intended to be conveyed only to the designated recipient(s). If you have >> any reason to believe you are not an intended recipient of this message, >> please notify the sender by replying to this message and then deleting it >> from your system. Any use, dissemination, distribution, or reproduction of >> this message by unintended recipients is not authorized and may be unlawful. >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "memcached" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to memcached+...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- This e-mail message (including any attachments) may contain information that is confidential, protected by the attorney-client or other applicable privileges, or otherwise comprising non-public information. This message is intended to be conveyed only to the designated recipient(s). If you have any reason to believe you are not an intended recipient of this message, please notify the sender by replying to this message and then deleting it from your system. Any use, dissemination, distribution, or reproduction of this message by unintended recipients is not authorized and may be unlawful. -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
