Re: Clobbering updates CAS
On Aug 12, 6:10 am, Dustin dsalli...@gmail.com wrote: On Aug 10, 12:13 pm, Ren jared.willi...@ntlworld.com wrote: Though, it would be nice if SET/CAS ops could return the new CAS value, I think. It does in the binary protocol. Ah nice, well it seems PHP's PECL Memcached extension doesn't support it. Wether that is because libmemcached doesn't yet, don't know. Jared
Re: Clobbering updates CAS
On Aug 12, 5:39 am, Ren jared.willi...@ntlworld.com wrote: Ah nice, well it seems PHP's PECL Memcached extension doesn't support it. Wether that is because libmemcached doesn't yet, don't know. libmemcached definitely does. The bindings just need to be updated.
Re: Clobbering updates CAS
On Aug 10, 8:11 pm, Ren jared.willi...@ntlworld.com wrote: On Aug 10, 4:26 pm, David Sheldon d...@earth.li wrote: On Fri, Aug 7, 2009 at 4:37 AM, Dustindsalli...@gmail.com wrote: On Aug 6, 6:26 am, Ren jared.willi...@ntlworld.com wrote: If the CAS operation succeeds, then its the currently running tasks responsibility to refresh the data in the cache, if it fails with RES_DATA_EXISTS, then someone else is taking care of the update. That's an interesting approach. I'd only fear a failure to actually update the value causing stale data to stick around longer than you'd like. Probably best to run those updates through your favorite job queue. I see this as a good idea. I think that the failure to update should be on the step where it puts back the original data with the extended expiry. If it cannot do this, then starting again will either read the stale data with extended expiry, or updated data. Either way, that thread will not update it. If the CAS op succeeds and the thread doesn't follow it up with an update later, no other thread will update it. Until either the expiration value used with the CAS op, or the embedded expiration value passes. Can you tell it not to use CAS (i.e. force the write) when it writes the updated data with new expiry after regeneration? If so, then it's unlikely that stale data will hang around longer. Just use a plain SET op. Though, it would be nice if SET/CAS ops could return the new CAS value, I think. Jared
Re: Clobbering updates CAS
On Aug 10, 12:13 pm, Ren jared.willi...@ntlworld.com wrote: Though, it would be nice if SET/CAS ops could return the new CAS value, I think. It does in the binary protocol.
Re: Clobbering updates CAS
On Fri, Aug 7, 2009 at 4:37 AM, Dustindsalli...@gmail.com wrote: On Aug 6, 6:26 am, Ren jared.willi...@ntlworld.com wrote: If the CAS operation succeeds, then its the currently running tasks responsibility to refresh the data in the cache, if it fails with RES_DATA_EXISTS, then someone else is taking care of the update. That's an interesting approach. I'd only fear a failure to actually update the value causing stale data to stick around longer than you'd like. Probably best to run those updates through your favorite job queue. I see this as a good idea. I think that the failure to update should be on the step where it puts back the original data with the extended expiry. If it cannot do this, then starting again will either read the stale data with extended expiry, or updated data. Either way, that thread will not update it. Can you tell it not to use CAS (i.e. force the write) when it writes the updated data with new expiry after regeneration? If so, then it's unlikely that stale data will hang around longer. David
