cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: Cachable Readers
Date Tue, 13 Aug 2002 13:24:48 GMT
> From: Amir Rosen [mailto:amir@cti2.com]
> 
> > -----Original Message-----
> > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> > Sent: Tuesday, August 13, 2002 2:35 PM
> > To: cocoon-dev@xml.apache.org
> > Subject: RE: Cachable Readers
> >
> >
> > > From: Amir Rosen [mailto:amir@cti2.com]
> > >
> > > Ok,
> > > Do you think this behaviour is going to be changed (fixed) soon
> > (someday) ?
> >
> > Amir,
> >
> > Caching works a bit different from what you think.
> >
> >
> > > > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > > >
> > > > Amir Rosen wrote:
> > > > >
> > > > > Ok, now it's my turn not to understand :)
> > > > > How do I access the cached object ?
> >
> > Cocoon caches *results* produced by the cocoon pipeline (with
validity
> > object - see below). It does not caches cocoon pipeline components
> > itself, because they are pooled and *reused*.
> >
> >
> > > > Ah, a weak point - yes, you're right you don't have
> > > > access to the cached object.
> >
> > And it is not needed. Sitemap component is given all the
> > information it
> > needs (in setup method) to re-create situation which was at the
moment
> > of creating cached response. After that, (cacheable) component is
able
> > to tell on what external / environmental conditions depends
> > its output,
> > and generates validity.
> >
> > To determine whether response which could be generated right now is
> > different from the response generated some time ago and cached,
these
> > validity objects are compared. If there were no changes, then Cocoon
> > takes cached response and *re-plays* it, like a sound record,
> > *without*
> > using sitemap component.
> >
> 
> I absolutely agree with your description of the caching mechanism,
only
> it doesn't exactly work that way for readers (which was my point for
starting
> this thread).
> 
> Readers generate 3 things that should be cached: the mime-type, the
last
> modified
> date, and the binary output. When a validity check causes the use of a
cached
> output
> from a reader, all these 3 should be used from the cache, and not like
it
> works
> now, that only the binary data is used from the cache, and the other
two are
> generated again from the newly setup()ed reader.

Aga! Yes, you are right, it totally makes sense to cache these together
with binary output. CachedStreamObject and CachingStreamPipeline (2.0.3
- speak) should be modified to accommodate this.

Vadim


> Amir
> 
> 
> > > > > Do you mean I should Implement the caching by myself ?
> >
> > You need only to create Validity object, which can store any
> > information
> > you need. Just make sure you have comparison method and your
> > validity is
> > Serializable (cache lives longer then Cocoon instance!).
> >
> > > > No, I thought it would work the other way. So, if you
> > > > really need this feature (accessing the cached object),
> >
> > As pointed out above, there is no notion of cached *object*, but
there
> > is cached *result*, which is set of XML events (or bytes), plus
> > validity.
> >
> >
> > > > you have to take care of the caching yourself.
> >
> > It's enough to take care of validity object.
> >
> > Vadim
> >
> > > > Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message