Clobbering updates & CAS

[Ren]

The FAQ outlines a method of reducing the effects of clobbering
updates, by use of an embedded expiration value.

http://code.google.com/p/memcached/wiki/FAQ#How_to_prevent_clobbering_updates,_stampeding_requests

"Then, when you get from the cache and examine the timeout and find it
expired, immediately edit the embedded timeout to a time in the future
and re-store the data as is."

If a CAS operation is used here, wouldn't it prevent others from doing
unnecessary work?

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.

Jared

[Dustin]

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.

[Ren]

Using a short (but long enough for the update to work in) TTL on the
CAS operation would cause the stale data to expire, sooner rather than
later.

But yes, a job queue would be more ideal.

Jared

[David Sheldon]

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

[Ren]

On Aug 10, 4:26 pm, David Sheldon <d...@earth.li> wrote:

> On Fri, Aug 7, 2009 at 4:37 AM, Dustin<dsalli...@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.

Jared

[Ren]

Though, it would be nice if SET/CAS ops could return the new CAS
value, I think.

> Jared

[Dustin]

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.

[Ren]

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

[Dustin]

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.