Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
From: Sylvain Wallez <sylvain@apache.org>
Subject: Cache keys with request metadata (was Re: Accessing cache validities
 from flow)
Date: Fri, 19 Dec 2003 10:44:18 +0100
Lines: 34
Message-ID: <bruh9j$ih7$1@sea.gmane.org>
References: 
 <1E0CC447E59C974CA5C7160D2A2854EC097D4F@SJMEMXMB04.stjude.sjcrh.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
In-Reply-To: 
 <1E0CC447E59C974CA5C7160D2A2854EC097D4F@SJMEMXMB04.stjude.sjcrh.local>
Sender: news <news@sea.gmane.org>

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