"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.
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.
On Aug 7, 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.
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.
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.
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.
> 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.
> 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.
Though, it would be nice if SET/CAS ops could return the new CAS value, I think.
