cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stevenson, Chris (SSABSA)" <>
Subject RE: [RT] Cocoon in cacheland
Date Wed, 29 Nov 2000 00:03:38 GMT
> > If you are referring to Component Pooling, then I beg to differ.
> > Any object that will see heavy use should be pooled: instead of
> > having 100 different threads handling 100 different users, Cocoon
> > should employ the approach of pooling Sitemaps, Parsers, 
> InputSources,
> > Transformers, and Serializers.
> Uh. No, he doesn't. I don't think. I *think* he meant XML
> stream caches (see below)

Yep. Pools are another (albeit important) issue entirely. 
Lets just concentrate on caching.

> Can we define some terms here guys - I think we need to be
> absolutely crystal clear what we're talking about, otherwise
> it's all meaningless:
> * Cache
>   A collection of resources (that is data) upon which the Cocoon
>   code operates.
>   There are several types of cache:
>   1) XML stream caches
>      Cache XML streams INSIDE the pipeline.
>   2) Serialized data caches
>      Cache the results of a request OUTSIDE the pipeline.
>   3) Independant cache
>      (can anyone think of a better name? this one is horribly
>      ambiguous)
>      A cache contained and maintained within a component.

Component-managed cache?

I think we also need 
4) Do not cache
If a component must always be regenerated

This made me think. (Hopefully a good thing :-)

Part of the solution seems to be a way for the components to
inform the cache system what kind of caching is appropriate...

Note that the cache relevant to a component is its *input* 
So if a component maintains an internal cache, the system doesn't
need to cache the *input* to that component. It may still cache
the output from the component. 

The serialized data cache is only important at the end of the 
pipeline (the serializer), and therefore is irrelevant to
the internal caches, which will be SAX caches. (Is this true?)

[ASIDE: some components like fop actually use DOM, not SAX 
internally. If they had a way to tell the system 'give me DOM'
then the system might be able to efficiently cache the DOM
rather than SAX events. In a pipeline of DOM based filters
there would then be no need to convert DOM -> SAX ->DOM
all the time. Just a thought.]

A dynamic component with an independent cache might specify
3) Independent cache so that the system doesn't cache its input

A generator will always use an internal cache since the system
cannot determine what to cache. (Is this true?)

so we might have a method on Component like:

public static int CACHE_NONE = 0;
public static int CACHE_SAX_INPUT = 1;
public static int CACHE_COMPONENT_MANAGED = 2;

public int getCachingHint();

Then it becomes very simple for the system to detemine what 
(if anything) to cache.

View raw message