> -----Original Message----- > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 13, 2002 2:35 PM > To: [EMAIL PROTECTED] > Subject: RE: Cachable Readers > > > > From: Amir Rosen [mailto:[EMAIL PROTECTED]] > > > > 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:[EMAIL PROTECTED]] > > > > > > 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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
