cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: Accessing cache validities from flow
Date Thu, 18 Dec 2003 22:10:03 GMT
Sylvain Wallez <> writes:
> We're talking about validities, but before checking a 
> validity, we first 
> have to obtain it through the cache key.
> In the current Cocoon architecture, keys of cache entries are 
> built with 
> abitrary data defined by each of the individual pipeline 
> components. The 
> result of this is that we can have several different cached responses 
> for a single request definition (URI + headers).
> The big benefit of this approach is that many variations can 
> be cached 
> (depending on night/day, local weather, whatever), but the main 
> disadvantage is that the pipeline *must* be built for every 
> request in 
> order to compute the cache key, even if the response is 
> served from the 
> cache afterwards.
> A solution would be to have another pipeline implementation 
> that uses a 
> different strategy to build cache keys. What comes to mind is that 
> instead of returning abitrary values for key, components could return 
> some matching criteria on request metadata. The pipeline could then 
> organize the cache entries by URIs, each URI having a list of cached 
> responses along with the matching criteria.
> This approach would reduce the possible cached variations for a given 
> request, but would allow to find cached content (and its validity) 
> without incuring the cost of building the pipeline.
> What do you think?

That's sort of one of the things that we are doing, only within the
current Cocoon infrastructure:  in some places we maintain our own
static hash map of key strings that map to Cocoon validities.  We can
the look up a Cocoon validity and have it mark itself invalid.  The key
strings we build are based purely on the metadata for the data in
question (or sometimes the metadata about the metadata, since the whole
system is metadata driven).  We really need to be able to maintain a
multi-level hierarchy of dependencies and it would be nice if we didn't
have to build the code ourselves...

View raw message