cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergio Carvalho <scarva...@criticalsoftware.com>
Subject Re: idle thoughts in caching in c2
Date Fri, 19 Jan 2001 17:42:49 GMT

Good analysis. I'd like to signal a warning that I've already pointed out on another thread,
while discussing this issue with Giacomo: Current Cocoon 1 processors are responsible for
answering to questions 1 and 2, and the algorith to answer cannot be defined at design time,
as there is not enough information. 

In my opinion, caching components should be part of the pipeline, allowing for different caching
methods to be used, and combined with the different processors. In this scenario, cache doesn't
even need to be snapshot-based. 

On Thu, 18 Jan 2001 00:16:46 -0500 (EST)
Donald Ball <balld@webslingerZ.com> wrote:

> when an environment is processed by a sitemap, a new ResourcePipeline is
> constructed, then the environment is associated with a pipeline in the
> sitemap, and the ResourcePipeline is configured to match that pipeline,
> and the environment is processed by the pipeline object.
> 
> to add caching behavior, the first thing to do is re-use ResourcePipeline
> objects. for instance, if this (generated) test is successful:
> 
> if ((map = wildcardMatch(matcher_wildcard_N138_expr,objectModel)) != null) {
> 
> we should operate on ResourcePipeline_N138, or a clone thereof if it's not
> threadsafe. The ResourcePipeline should store the results of each of its
> stages (let's call those results snapshots) when the following criteria
> are met:
> 
> 1. it is likely that the snapshot will be valid for another Environment
> 
> 2. the cost of matching an Environment to a snapshot plus the cost of
> determining if the snapshot is not stale plus the cost of retieving the
> snapshot from storage is less than the cost of generating the snapshot
> anew
> 
> for a first pass, i think we can assume that (1) will be true for
> components like the FileGenerator, but not true for components like the
> ServerPagesGenerator. in another iteration, perhaps we can define some way
> in which server pages and other dynamic components can tell the sitemap
> what environmental conditions cause their results to vary (e.g. a specific
> request parameter and a specific cookie), but i think that would just add
> complexity right now.
> 
> cacheable components could be wrapped with a general purpose component
> wrapper, which would take its incoming SAX events, store them in some
> fashion (using XMLCompiler maybe?), and retrieve them on demand. the
> underlying component would have to provide a method by which the wrapper
> component could determine if its stored snapshot was valid for a given
> environment.
> 
> snapshots would be referenced via strong references if they're frequently
> used, and downgraded to soft references if the cache gets larger than
> desired. any number of algorithms could be used to decide which snapshot
> references to soften, and it should be easy to change algorithms.
> 
> so good so far? i reckon this is a fairly obvious approach to those
> experienced c2 developers who've given any thought to this. anyone see any
> holes in it? worth taking any further?
> 
> - donald
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


-- 
Sergio Carvalho
---------------
scarvalho@criticalsoftware.com

If at first you don't succeed, skydiving is not for you

Mime
View raw message