cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timm, Sean" <ST...@mailgo.com>
Subject RE: cache thoughts
Date Wed, 23 Feb 2000 23:40:54 GMT
The following is a quick overview of the MemoryStore situation from my
perspective:

The MemoryStore class is currently hard-coded to ensure that at least
500,000 bytes of memory are available to the JVM at all times.  The cache
will be very ineffective, and you probably wouldn't see any performance
improvements if you don't have enough memory available for the JVM beyond
this.

Everything using the MemoryStore for object storage that is URL or
file-based is currently using the Monitor class to determine when a
timestamp has changed (at least what I've found so far).  The problem is
that each object is keyed off of the HttpServletRequest object (munged by
Utils.encode).  I'm hitting the same URL with a different stylesheet...hence
my problem.

All hasChanged() calls expect the HttpServletRequest to be passed in (even
though the parameter is declared as type Object, the CocoonCache class
passes in a request object to everything that implements the Changeable
interface, so hasChanged() currently has to handle receiving an
HttpServletRequest object).  In effect, hasChanged() calls are passed off to
each processor or producer, but the only thing passed to them is the request
object.  For those using the Monitor, this request object is munged and
passed to the Monitor as a lookup key to see if the object has changed from
the last recorded timestamp.  This is where the real problem is.  The
Monitor cannot just base the key off of the request object...it has to
include the resource name being stored as well (the XSL stylesheet location
and name, for instance).

So...thoughts? (Hopefully I wasn't too unclear...)

- Sean T.

-----Original Message-----
From: brian moseley [mailto:ix@maz.org]
Sent: Wednesday, February 23, 2000 1:12 PM
To: 'cocoon-dev@xml.apache.org'
Subject: RE: cache thoughts


On Wed, 23 Feb 2000, Timm, Sean wrote:

> Ah...clarity is not always my forté.  :)  For instance,
> we are hitting http://localhost/myweb/file.xml.  This
> URL doesn't change, but depending on the data POSTed to
> the url, the stylesheet we process against it does
> change.  Unfortunately, the stylesheet processor just
> looks at the URL and says that it hasn't changed, so it
> serves it out of cache instead of reloading it if the
> file has changed.

suggestion: how about adding some time of ChangePolicy
abstraction to the framework. attach a ChangePolicy object
to each cached object, so the 'is it changed' question can
be delegated to the ChangePolicy object.

Mime
View raw message