Cache (wraps) Transient Store (may use) Persistent Store encapsulating all cached Pipelines.
For example, with IncludeCacheManager using a potentially different store, the StatusGenerator and the un-cache actions (and any parallels in flow) will fail to find all cached content unless I have missed something in the new code (which I haven't thoroughly read, so please forgive me if I missed it).
I've been working on event driven cache invalidation and need to understand if there is a new contract surrounding where CachedContent
can live and if this new stuff presents a real or only theoretical conflict. I'm really only referring to CachedResponse objects stored
under PipelineCacheKeys.
Do others see a need to solidify this contract?
Looking into the cinlude transformer, I have the following questions:
- Why is this separate caching needed? Why not just use the cocoon: protocol to call a cacheable pipeline?
- Does the configurable/parameterizable cache exist only for this reason from the javadocs?:
"
Usually the content is cached in the usual store, but you
* can also define a writeable source with the <code>source</code> parameter,
* e.g. "file:/c:/temp". Then the cached content is written into this
* directory.
"
I can't get my pea brain around why one would want/need to do that and not just configure the existing persistent store as they choose.
It seems to me that the business of the cinclude transformer should be to support cacheability of included pipelines but not actually interact with the cache - that seems to be the business of the pipeline. Am I way off?
Geoff
