Hi Geoff, I'm working on the exact same thing as you are. The specific backend in my case is an XML database that is updated by a different subsystem than cocoon and I'd like to be able to let the the cocoon caching framework know about the changes going on there.
> I am working on a process for external cache invalidation for > use in Cocoon. To get right to the point, what would the > opinion be of exposing something like SourceValdity[] > getValidities() on AbstractAggregatedValidity? The purpose > would be not to alter the validities, but to examine them. > > If validities are externally invalidated, how do you accomplish this? Yes, this seems to be a blind spot in the caching component, it delegates the responsibility of handing out a validity strategy to the individual components that make up a pipeline. > In the Cocoon cache (which uses Excalibur store) a Pipeline > result and key are placed in the store. The result holds a > SourceValidity array and exposes getValidities() so that they > can be tested upon retrieval from the cache before use. ... leaving pro-active cache invalidation difficult to implement. > I don't think an > expiration scheme is a good solution. Me neither. > > What I'd like to do instead is have each validity Just for clarity, you are talking about excalibur.source.SourceValidity? I assume this validity object also has a way of identifying the Source it is a validity object of, like its uri string or something, in order for events referring to the same source to be matched. > register > it's dependencies and the key under which it is stored with > the event processor upon going into the cache. When an event > is received, the processor would look up those keys and > remove the items from the cache (it could just mark them > invalid, but why bother to keep them around at all?) When > the validity is created, it doesn't know what key it is being > stored under, and probably shouldn't care. So, I think the > place to handle this registration is when the item goes into > the cache. I agree. > In cocoon, there is a wrapper around the store implementation > that would be a good place to handle this - I can check for > these special validities and handle them when I have the key > right there, and can unregister when the item is removed, > etc. The hitch I've run into is with aggregated validities > which is where the proposal above comes from. I think it is very natural for an aggregated validity to expose its composite validities. I'm all for it! > > Very open to other suggestions and input and sorry for the > long post, Geoff Howard I think your approach is excellent. My current implementation depends on the individual cacheable components to be aware of a validity cache that receives events from the backend. The obvious problem with this is that it is not very general and requires each individual component to be aware of that validity cache. Have you committed any of your work to cocoon yet? I would be very interested in seeing the code. If there is anything I can do I would like to help out. Regards, Unico --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
