So memcache.cas and memcache.add could also miss just like memcache.set? Are these documented somewhere. I mean I would love to see a API documentation that details every scenario :) I will read this above link on Error Codes.
On Friday, June 24, 2016 at 11:35:28 PM UTC+5:30, Colin Pitrat wrote: > > 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 <[email protected] > <javascript:>>: > >> 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 <[email protected]>: >>>> >>>>> 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 [email protected]. >>>>> 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 [email protected] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
