cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Cache keys with request metadata (was Re: Accessing cache validities from flow)
Date Fri, 19 Dec 2003 09:44:18 GMT
Hunsberger, Peter wrote:

>Sylvain Wallez <sylvain@apache.org> 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...
>  
>

Well, seems like you may have a good starting base for something that 
can be developped here. Dare to share?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message