httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Possible new cache architecture
Date Mon, 01 May 2006 21:07:39 GMT
Graham Leggett wrote:
> Brian Akins wrote:
>>> That's two hits to find whether something is cached.
>> You must have two hits if you support vary.
> You need only one - bring up the original cached entry with the key, and 
> then use cheap subkeys over a very limited data set to find both the 
> variants and the header/data.
>>> How are races prevented?
>> shouldn't be any.  something is in the cache or not.  if one "piece" 
>> of an http "object" is not valid or in cache, the object is invalid. 
>> Although other variants may be valid/in cache.
> I can think of one race off the top of my head:
> - the browser says "send me this URL".
> - the cache has it cached, but it's stale, so it asks the backend 
> "If-None-Match".
> - the cache reaper comes along, says "oh, this is stale", and reaps the 
> cached body (which is independant, remember?). The data is no longer 
> cached even though the headers still exist.
> - The backend says "304 Not Modified".
> - the cache says "cool, will send my copy upstream. Oops, where has my 
> data gone?".

I think that can be avoided by, instead of reaping the cached body, actually
setting aside the cached body (public > private), by changing it's key or
whatnot.  Then - throw it away after the backend says "200 OK", and replace
it with something new.  Or, rekey it a second time (private > public) when
the backend reports "304 NOT MODIFIED".

In the race, one will set it aside looking for another, the second will make
a fresh request (it doesn't see it in the cache), and either the first or
second request will wrap up -last- to place the final copy back into the
cache, replacing the document from the winner.  No harm no foul.


View raw message