--On August 17, 2005 9:29:05 PM +0100 Colm MacCarthaigh <[EMAIL PROTECTED]>
wrote:
Why bother renaming the file for such an implementation? If a
half-cached file can be served from, and this handled properly, the
rename would no longer make any sense :)
For a disk cache it would be tricky to discern between a cached file
that is half there due to a sudden httpd exit, and a cached file that is
half there because a proxy or CGI backend is blocking.
Exactly. This is why I've avoided this functionality. I don't think it
can be implemented effectively or efficiently.
I absolutely dislike the idea of stalling a request because another
worker/thread *might* be fetching it. We should never purposely stall a
request because another worker *might* have a request outstanding.
One solution that avoids that may be to create random uuid at httpd
start time, and store that in every cache object. That way the caching
layer can determine if the half-cached file on disk belongs to a
"current" instance of httpd - and we assume it's in-flight - or if it
belongs to a previous instance of httpd, and we assume it's leftover
from a sudden death.
It doesn't handle the case when a sibling died. -- justin
