httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: Possible new cache architecture
Date Mon, 01 May 2006 20:46:44 GMT
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 

- 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?".

The end user will probably experience this as "oh, the website had a 
glitch, let me try again", so it won't be reported as a bug.

Ok, so you tried to lock the body before going to the backend, but 
searching for and locking the body would have been an additional wasted 
cache hit if the backend answered with its own body. Not to mention 
having to write and debug code to do this.

Races need to be properly handled, and atomic cache operations will go a 
long way to prevent them.


View raw message