cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Williams" <>
Subject lastModificationDate misuse? - old thread - progress
Date Sat, 09 Aug 2003 18:32:50 GMT
I have been mystified by the symptoms of the problem raised by Stuart Roebuck some time ago
on cocoon-dev and I can't see if/when it has been fixed or a workaround/hack avail:

If XSP is the result of a pipeline then the ServerPages Generator can't work out its currency
and randomly re-generates and compiles. To make matters worse if the XSP has the code necessary
for resultant objects to be cached then the code generated and compiled is not even used,
ie a cached object is used instead.

I have inspected the code of 2.0.4 and it is still there, ie code is same as when reported
in 2001. Surely a typical use of cocoon is to build XSP using XSLT?


Stuart Roebuck wrote:
>>On Tuesday, August 14, 2001, at 04:04  pm, Carsten Ziegeler wrote:
>>> In are the lines:
>>>> // the event pipeline is cacheable
>>>> // now calculate a last modification date
>>>> String hashKey = pck.toString() + validity.toString();
>>>> this.lastModificationDate = HashUtil.hash(hashKey);
>>> this is used in
>>>> /*
>>>>  * FIXME: It's the program (not the instance) that must
>>>>  * be queried for changes!!!
>>>>  */
>>>> if (programInstance != null &&
>>>> programInstance.modifiedSince(source.getLastModified())) {
>>>>   // Release the component.
>>>>   release(programInstance);
>>> consequently, any use of the ServerPages Generator which takes an input
>>> from within the sitemap (e.g. using a "cocoon:/" URI) will result
>>> in (on a
>>> practically random basis) certain XSP (et. al) pages being regenerated
>>> over and over again, and will potentially prevent updated XSP (et. al)
>>> from being properly regenerated.
>> Hm, that is true. The problem is that I don't saw any other way to
>> implement the lastModificationDate for the SitemapSource than hashing
>> the key.
>> Usually this modification date is used in the caching algorithm
>> and is there only tested against equal. So there this hack works.
>> Any solution for this?
>For the caching, I presume there is a mapping of hashKeys to 
>serializedResults.  If this is true, then couldn't these also map to a 
>date-stamp of when the result was cached and have lastModificationDate = 

View raw message