I like all that -- assume it would involve fairly invasive restructuring of the whole pipeline process, but need to go read up on the prior discussion you mention.
Seems like from a performance standpoint, the per-pipeline setup is best: non-cached matches don't need to waste time checking a cache, and cached pipelines could be optimized to assume caching behaviour. I *really* like the external trigger/periodic system for caches. Related to that, how about this - I have been looking into extending the current store/generator relationship to allow generators to report dependencies and have the store track which keys (however they are created) are related to which dependencies. In the situation where a database trigger on update/delete needs to signal cache removal/invalidation (i favor removal in this case) the store could expose a removeByDependency(Object obj) function and just look up the relevant keys in its own dictionary. The number of types of dependencies isn't too great (in our case maybe 10). Currently I think the store would need to iterate over every key and match strings or compare hashes. Carsten let me know that the store is moving to excalibur and I haven't been able to look into whether they define anthing like this or not. Anybody know off hand? -----Original Message----- From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 21, 2002 11:29 AM To: [EMAIL PROTECTED] Subject: Re: [RT]: Calculating the cache key Geoff Howard wrote: >The performance of key comparison is especially important for high traffic >sites (like ours). An idea I've had to decrease this importance is: > >An *option* to have the pipeline do asynchron cache validation - if a cached >item exists, use it *then* check it's validity (or cause it to be checked) >and remove it from the store if it was expired. This is attractive to us >because we'll have many steps that will need to be checked (many of our >pages will involve 5 or 6 or more generators aggregated and included) and >the performance hit of generating and comparing all those keys is scary. >This integrates well with the external cache validity concept that Marcelo >Ochoa/DBPrism has been working on. > Geoff, this a really good use case for the need of per-pipeline choice of the pipeline implementation, which has been discussed some time ago : - webapp pipelines *must* use up-to-date content (i.e. cache validity is always checked, or no cache is used at all) - content publication pipelines don't need to be checked synchronously at each request, and the cache can be checked either periodically or through external triggers. So we end up with 3 main types of pipelines : - non-caching, - caching and synchronously validated, - caching and asynchronously validated. Thoughts ? Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
