Few queries on atomicity of requests

[Dean Harding]

Stephen Johnston wrote:
> /--- FROM THAT ARTICLE ---/
> /Alexey describes a different two key approach:/
> 
> Create two keys in memcached: MAIN key with expiration time a bit higher 
> than normal + a STALE key which expires earlier.
> 
> On a get read STALE key too. If the stale has expired, re-calculate and 
> set the stale key again.
>  
> ------------------------------------------------------
> Can anyone explain a bit more about how this combats the dogpile effect? 
> It seems to me that this just means the STALE key will cause the dogpile 
> if all of the visitors are getting the STALE key also and the STALE key 
> is, in effect, determining the actual re-calculation timing. It seems to 
> me the description above is missing something.

Basically, you update the "STALE" key *before* you recalculate the main 
key. All it does is reduce the window where there is nothing cached.

One thing I like to do is you basically have two windows, a "fresh" 
timeout and a "stale" timeout. During the "fresh" timeout, the item from 
the cache is good enough. During the "stale" timeout, the item is coming 
up to expiry time, and it might be a good idea to start thinking about 
recalculating. So it looks, conceptually, like this:

+----------------------+----------------+--- ...
| fresh                | stale          |
+----------------------+----------------+--- ...
^ t = 0                ^ fresh timeout  ^ stale timeout

The "stale" timeout corresponds to the actual memcache timeout when 
it'll evict the item, the "fresh" timeout is serialized with the object 
I'm storing.

Now, each time I do a "get" of the item, I check the "fresh" timeout, 
and if it has expired, there is an x% chance that I'll re-calculate the 
item right then-and-there.

The value of "x" is determined by the number of request/second that item 
gets, and it also increases the closer we are to the stale timeout.

Basically, it means that after the "fresh" timeout, it's likely that 
only one or two requests will decide they want to re-calculate the value 
and all the rest will continue to the use the old value (until those one 
or two that decided to recalculate re-store the value).

I hope I explained that well enough :-)

Dean.