lastModificationDate misuse? - old thread - progress

[John Williams]

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? John     Stuart Roebuck wrote: >>On Tuesday, August 14, 2001, at 04:04  pm, Carsten Ziegeler wrote: >> >>> In SitemapSource.java 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 ProgramGeneratorImpl.java: >>> >>>> /* >>>>  * 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 = >lastCachedDate?