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