cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michel Lehon" <>
Subject RE: caching problem - more data
Date Fri, 14 Apr 2000 13:13:07 GMT
> From: Donald Ball []
> First of all, I explicitly disable the cocoon cache, so the only "caching"
> is done by the MemoryStore object by the XSLTProcessor object. I have
> three files:
> foo.xml
> foo.xsl
> foo2.xsl
> in a two stage pipeline. I added debugging code to XSLTProcessor to tell
> me when it's getting stylesheets from the store and when it's putting them
> into the store.
> request 1:
>   foo.xsl is put into store
>   foo2.xsl is put into store
> request 2:
>   foo.xsl is retrieved from store
>   foo2.xsl is retrieved from store
> request 3:
>   foo.xsl is retrieved from store
>   foo2.xsl is retrieved from store
> modify foo2.xsl
> request 4:
>   foo.xsl is put into store (??)
>   foo2.xsl is put into store

explained by your next mail. The whole pipeline is checked in
monitor.hasChanged using a MultiContainer if there is more than one item in
the pipeline.

> request 5:
>   foo.xsl is put into store (???)
>   foo2.xsl is put into store (???)
> request 6:
>   foo.xsl is put into store (????)
>   foo2.xsl is put into store (????)

Indeed all subsequent requests reload everything.
This is due to a bug (?) in Monitor.MultiContainer which adds resources for
the request to the vector of existing resources for the same request.

The MultiContainer contains elements like this:
Request 1:
foo.xsl, timestamp 1
foo2.xsl, timestamp 1b

request 2 & 3:
hasChanged() returns false, since no resource has been modified.

request 4:
foo2.xsl has been changed, so hasChanged returns true.
Every resource is reloaded:
foo.xsl, timestamp 2
foo2.xsl, timestamp 2b

The problem is the OLD elements are kept.

So Request 5+:
hasChanged returns true, because foo2.xsl (timestamp 1b) is still in the

> So I haven't managed to intentionally make it erroneously retrieve from
> the store after a modify, but I have made it do something wrong. Stefano,
> Michel, can y'all look into the MemoryStore and/or the XSLTProcessor to
> see if you can figure out why it's doing this?

With this mail you'll find two patches for and
They should fix the problem.

Instead of using a Vector for MultiContainer, this implementation uses a
Hashtable, with the (String)resource as a key.
And it checks for individual stylesheets updates (but still trying to be

I tested it it under Win98/Tomcat 3.1RC1/JDK1.2.2 and it seems to runs OK.
I tested with and without cache (well it still keeps the stylesheets in both

However it raises on more question:

what is the scope a a stylesheet ?
- A Request ?
- Itself ?

The current implementation monitors a stylesheet on the Request level; but
the Stylesheet is stored by itself in the MemoryStore.

So it means that:

Monitors :
 style.xsl for http://?????/??/foo1.xml (Request level)
and stores it in the MemoryStore as
 style.xsl (with path).

now foo2.xml is fetched, it also uses style.xsl.
 style.xsl is read again (it is new for the current request), gets
 and is stored in the MemoryStore (replacing the old (identical) one).

later foo1.xml is fetched.
 style.xsl did not change, so it is taken from the cache (but in fact it is
from the request of foo2.xml).

While in this example (I hope you understood my point, this explanation is
anything but clear ;))
this is no harm, if a lot of xml pages use the same (static) stylesheet, it
will be fetched over and over again.
This is same performance wise, but safe.

Could we monitor the stylesheets directly or do we need the request level ?
Do we have to add a request level for stylesheets in the MemoryStore ?

I'm asking because there might be implications I don't see with very dynamic

(The fix provided still monitors stylesheets on the request level).

In case my diff files are not good...
The complete files are available at:

> - donald

SAS DataWarehousing & Web Enablement.

View raw message