RE: InputModule output and pipeline caching ?
Ard Schrijvers <a.schrijvers <at> hippo.nl>
2006-05-01 09:42:25 GMT
>
> Hello
>
> AFAIK, Cocoon caching mechanism tries to cache a pipeline processing
> workflow "until it meets a non-cacheable element" (correct me if I'm
> mistaken :)).
>
> My question is rather simple, given the above hopefully correct
> assumption. If I have a pipeline with type="caching" that looks like :
Normal caching pipeline does not work like this:
A cocoon pipeline is only cached cached (apart from expiring cache which works little differnt, and the
CachingPointProcessingPipeline ), if EVERY single thing in it can be cached. So, if you have a very long
pipeline, with 100 transformers, all cached very well, except, for example, your last transformer not
(like a dynamic i18n transformer which is implemented in a noncaching pipeline), then, your entire
pipeline wont be cached! (cocoon tries to create just 1 cachekey for 1 pipeline. It can not have 1 cachekey
for the first parts of the pipeline (unless you are planning to use CachingPointProcessingPipeline))
If you have one single part in the pipeline which is uncacheable, there is no difference in performance
wether you use caching or non-caching pipelines.
But, if the last part of your pipeline is uncacheable, but for example the xml generator is, then you can use
in the map:part a src="cocoon:/cacheable/foo/bar"
and make sure that the /cacheable/foo/bar pipeline is cached. This way, at least the generation of you xml
is cached. This is more or less comparable to CachingPointProcessingPipeline I think....
>
> <map:match pattern="foo">
> <map:aggregate element="root">
> <!-- various map:part reading xml flat files on disk which are
> sometimes updated -->
> </map:aggregate>
> <map:transform src="{myinputmodule:someproperty}/foo.xslt"/>
> <map:serialize type="xml"/>
> </map:match>
>
> and given that the someproperty output value is dynamic, because based
> on dynamic request parameters the myinputmodule uses to alter that
> property :
This is certainly not a reason why it can not be cached (what about request-parameters passed into an xsl. An
xsl can still be perfectly cached!!)
>
> will Cocoon cache the first inputmodule return value, and use it until
> the cache has to be refreshed, or will it *instead* cache each and
> every inputmodule value returned ?
I dont really know what you mean, but it depends on your myinputmodule implementation
>
> in other words, will I end up with one cached xslt transformation
> bound to the first inputmodule value ever returned, or with multiple
> cached transformations, because Cocoon is "smart enough" to understand
> the transformer part uses a dynamic source, knowing that the {} might
> return different values ?
You just have to make sure, that depending on the request-param, your myinputmodule returns a cached
"someproperty" depending on the request-parameter you want it to depend on. (like an xsl
transformation, you pass in map:paramters, where the cache then also depends on ( unless you configure
"use-request-parameters" to "true" for xsl transformations, then it uses ALL request-parameters,
which you should never do if you ask me))
Hope this clears things up.
Ard
--
Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel +31 (0)20 5224466
-------------------------------------------------------------
a.schrijvers <at> hippo.nl / http://www.hippo.nl
--------------------------------------------------------------
>
> thanks
> laurent
>
>
> --
> <a href="http://in-pocket.blogspot.com">http://in-pocket.blogspot.com
> - Mobile world, technology and more</a>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe <at> cocoon.apache.org
> For additional commands, e-mail: users-help <at> cocoon.apache.org
>
>
and do undergo that mechanism as much as row-
elements appear, not only once as it is now .. (rember the rows of
"b" in (A))
Do you know an answer to that? currently it has driving me crazy for
5 hours ..
thanks and greetings
Andre
RSS Feed