Geoff Howard <cocoon@leverageweb.com> wrote:
>
> I've been waiting for this to come back up. I did a similar
> implementation
> in the past using JMS. I made an avalon component that
> subscribed to JMS
> events that could then be published by some back end process
> (in my case it
> was java stored procedures called on update, etc in oracle).
> The listener
> then interpreted the messages and located keys in the cache.
> Would that
> work as a start?
I suspect so. I'd love to have a look at it if you can.
> I could probably re-create that fairly quickly if you're interested.
We're interested!
>
> Geoff
>
> At 09:42 AM 5/23/2003, you wrote:
> >It seems to me that this must be a classic Cocoon problem,
> but I really
> >haven't found any discussion of it or how to solve it:
> >
> >We have a generator that creates some content (from a database via
> >EJBs) that for 99.99% of the time is unchanging. Every once and a
> >while an end user (with admin rights) will make a change to this
> >content and immediately expect all users to be able to see
> the changes
> >upon a subsequent refresh of the relevant screen. The content is
> >expensive to generate and it makes sense to cache it. We
> could in fact
> >cache it once and for ever if we didn't have the occasional update.
> >
> >Is there currently any way to have the back end signal to
> Cocoon that a
> >particular cache item needs to be invalidated? We're thinking of
> >building a MX Bean listener that would register itself with a common
> >proxy super class for all EJBs. Then upon successful insert
> or update
> >on the back end the proxy classes would signal the listener to blow
> >away the particular cache entry. Essentially this would be
> something
> >like a BackEndListenerCacheValidty (or BackEndCheckingCacheValidity
> >although it doesn't really check) class. Does this make sense? Does
> >Cocoon or anyone have anything like this already?
> >
> >Peter Hunsberger
|