httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject mod_cache: atomic cache updates
Date Fri, 03 Sep 2010 00:09:55 GMT
Hi all,

A second issue I would like to attack this weekend is the issue of  
atomic cache updates in mod_cache.

Right now today, two functions are provided to add and/or update a  
cache entry:

     apr_status_t (*store_headers)(cache_handle_t *h, request_rec *r,  
cache_info *i);
     apr_status_t (*store_body)(cache_handle_t *h, request_rec *r,  
apr_bucket_brigade *b);

The problem is that two possible cache update scenarios exist:

- Add response to cache: first, store_headers is called, followed by  
one or more calls to store_body until we see an EOS bucket to say  
we're done.
- Freshen existing cached entity by updating headers only:  
store_headers is called only, and store_body is never called at all.

The store_headers implementation cannot know if mod_cache intends  
calling store_body at a future time, and so cannot make a safe  
decision as to whether to write the headers now, or delay the writing  
of headers until the body has been downloaded fully. I believe this  
issue may be the cause of some cache edge case problems I have seen  

What we're missing is a "commit" function, to say "mod_cache is now  
done, implementation, please make your cached entity available for  
others to use".

We could hack this by creating a "commit" function and then wiring it  
into a cleanup registered with r->pool, but the cleanup only runs when  
the request has been acknowledged by the client, which happens eons  
later (in computing terms). We're a cache, and our reason for  
existence is performance, we ideally want to commit our cached entity  
and make that entity available as soon as we receive the complete  
request from the backend, not when the response is finally eventually  
acknowledged by the client on the frontend and r->pool is destroyed.

I propose we add a dedicated function as follows, to indicate to the  
implementation "mod_cache has given you all the information you need,  
make it so":

     apr_status_t (*commit_entity)(cache_handle_t *h, request_rec *r,  
cache_info *i);

This should remove all doubt in the implementation as when to make a  
cached entity available.


View raw message