httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <d...@haxent.com.br>
Subject Re: Possible new cache architecture
Date Mon, 01 May 2006 21:08:51 GMT
On Mon, 01 May 2006 22:46:44 +0200
Graham Leggett <minfrin@sharp.fm> 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?".

Sorry, but this only happens in your imagination. It's pretty obvious
that mod_cache_http will handle this.

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

No.

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

Locks are not necessary, perhaps you are imaginating something very different.
If a data body disappears under mod_http_cache it is not a big deal! It will
refuse to serve the request from the cache and a new version of the page will
be cached.

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

I think we are discussing apples and oranges. First, we only want to *organize*
the current cache code into a more layered solution. The current semantics won't
change, yet!

--
Davi Arnaut

Mime
View raw message