cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amir Rosen" <a...@cti2.com>
Subject RE: Cachable Readers
Date Tue, 13 Aug 2002 13:57:13 GMT

> -----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.

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
> 
> 

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


Mime
View raw message