It depends on which client you used. For libmemcached: http://docs.libmemcached.org/libmemcached/memcached_return_t.html
2016-06-24 18:37 GMT+01:00 Nishant Varma <tnish...@zeomega.com>: > Also helpful if we have a detailed API documentation with error codes? > Trying to read this but not so sure if I got it right > https://github.com/memcached/memcached/wiki/BinaryProtocolRevamped > > > On Friday, June 24, 2016 at 10:28:41 PM UTC+5:30, Nishant Varma wrote: >> >> 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>: >>> >>>> 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. >>>> 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. > -- --- 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.
