cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject [proposal] was RE: Backend cache invalidation
Date Tue, 27 May 2003 12:59:56 GMT
[the context for this is in the original message preserved

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.  This is a good problem because I think the solution I
cooked up before was based on examining strings and was a shortcut
while I thought about issue below. I didn't yet 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 based on
those dependencies (possibly only removeByDependency(key, value)? ).

I think this could be accomplished cleanly by:
1) Create a new Validity object that exposes a getDependencies()
method.  An interface would help generalize the contract with
the store.
2) a new Store implementation would internally map dependencies to
keys and expose removeByDependency(key, value).  The JMS component
then would call this method on the store in its onMessage() handler.

What do others think?


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!
> >
> > 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

View raw message