httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: mod_cache responsibilities vs mod_xxx_cache provider responsibilities
Date Sun, 17 Sep 2006 20:47:06 GMT
Niklas Edmundsson wrote:

> However, I don't see how you can do a lockless design with multiple 
> files and an index that can do:
> 
> * Clients read from the cache as files are being cached.
> * Only one session caches the same file.
> * Header/Body updates.
> * No index/files out-of-sync issues. Ever.

Thinking about this some more I do see a race during purging - a cache 
thread could read the header, the purge deletes header and body, and 
then the cache thread reads the body, and interprets the missing body as 
"the body is still coming".

One possible (and reasonably simple) solution would be to cache the 
header and body in a unique directory - the directory name becomes the 
key, and the entry is either cached completely / still being cached if 
the directory exists. This assumes it's possible to atomically delete 
directories.

Another option is to version the filename of the body based on a key in 
the header. In other words, in the header, called <key>.header, is a 
version number <timestamp>, meaning there should be a body called 
<key>.<timestamp>.body. A replacement cached entry therefore cannot 
stomp on what pre existing threads are doing. If the body file is 
created first, before the header file, then a non existent body file 
means "this entry has been invalidated, try the request again".

There is an assumption that <timestamp> is fine grained enough to be unique.

You're right, this is a tricky one, but there is a solution out there.

Regards,
Graham
--


Mime
View raw message