cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject RE: Backend cache invalidation
Date Tue, 27 May 2003 12:02:21 GMT
Ok, I looked at this over the weekend, and I have good news
and bad news.  Starting from scratch it was pretty trivial
to create an Avalon component that starts up with cocoon
and subscribes to any number of JMS topics.  It's in a messy
state on my hard drive at home but I could clean it up and
commit it to scratchpad or as a block.

The problem is that since I did this last time there's been a
change in the Cache keys.  They used to be strings, but now they
are int.  I didn't get to dig into the new implementation, but
it bears a discussion: what is a good way to allow the outside
world to report updates to resources in a way that the cocoon
cache can understand and act accordingly without mixing concerns.

The cache lets you look up an object based on key, and if you have
a pipeline, you can get the keys from each component.  But it seems
we would need a new facility: components that wish to be uncached
from the outside world would need to report their dependencies in
a generic way (key value pairs?) and the cache would need to record
which dependencies map to which keys and expose methods to deal by

At 10:15 AM 5/23/2003, Peter wrote:
>Geoff Howard <> 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!

View raw message