Actually, just to clarify. My understanding of CAS may be wrong though...
Memcache doesnt "ensure that the value of the object will bot be changed after get and before set" It is not a lock. What it does is ensure that the SET does not happen if something has changed the value after the GET. eg. GET+CAS <do some things> <no other clients change that value> SET+CAS ! success or GET+CAS <do some things> <another client changes the value> SET+CAS ! fails. CAS does not stop the value from changing. It stops you from setting a value if it has changed since you did a GET. In which case you would need to handle it in whatever way suits your situation. On Fri, Nov 7, 2008 at 4:22 AM, Dustin <[EMAIL PROTECTED]> wrote: > > > On Nov 6, 9:39 am, jainy <[EMAIL PROTECTED]> wrote: > > What issues can I have while using CAS ? > > > > Is it atomic ? > > > > I believe its > > > > get and check + set > > > > Does memcached ensures that value of the object will not be changed > > after get and before set ? > > Yes, this is the entire point of a CAS operation (otherwise, you'd > just use get and set). -- "Be excellent to each other"
