> >> Ard Schrijvers wrote: >> >> See: http://cocoon.apache.org/2.1/userdocs/concepts/caching.html >> > >> > About that page, and then particularly >> > >> > "The Default Caching Algorithm >> > >> > The default algorithm uses a very easy but effective approach to cache a request: The pipeline process is cached up to the most possible point. >> > >> > Therefore each component in the pipeline is queried by Cocoon if it supports caching. Several components, like the file generator or the xslt transformer support caching. However, dynamic components like the sql transformer or the cinclude transformer do not. Let's have a look at some examples:" >> > >> > is just not right. The default algorithm for a pipeline cache either results the entire pipeline OR nothing of it! This is important to know when you are looking for performance flaws. >> Are you absolutely sure of this? I could swear I've seen >> this working >> as described. > > Just try the following:
<snip/> > Running /foo again result in 1 single cached pipeline, namely > cocoon:/cached. > > This seems to be consistent with what I wrote about the caching mechanism: > A pipeline is cached if, and only if, every single component is depends on > is cacheable Your example certainly works like you describe, but I don't think that is what the documentation text is talking about. You're talking about calling sub-pipelines as part of an aggregation/generation, but the documentation is talking about pipeline components (generator, transformer, serializer). Consider a counter-example: <map:generate src="myfile.xml" /><!-- cacheable --> <map:transform type="xslt" src="transform1.xsl" /><!-- cacheable --> <map:transform type="sql" /><!-- non-cacheable --> <map:transform type="xslt" src="transform2.xsl" /><!-- normally cacheable but not in this case since it follows a non-cacheable component --> <map:serialize /> I believe that what happens, and what the documentation text is describing, is that when this pipeline is first executed it caches as much of the pipeline as it can: in this case the output from the first two components, since those are the cacheable ones. Then on subsequent requests it uses that cached output and feeds it directly to the sql transformer, without running the first two components again. This is not consistent with your statement "The default algorithm for a pipeline cache either results the entire pipeline OR nothing of it!". Part of the pipeline is being cached. Now, say you make a change to transform1.xsl, so the first map:transform reports its cache validity as being invalid. Now here it *is* all-or-nothing; the entire pipeline is regenerated from the first component. But this is still consistent with the documentation. --Jason --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
