cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject idle thoughts in caching in c2
Date Thu, 18 Jan 2001 05:16:46 GMT
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


Mime
View raw message