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
recently.
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.
Regards,
Graham
--
