cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [proposal] was RE: Backend cache invalidation
Date Tue, 27 May 2003 14:38:21 GMT
Geoff Howard <> writes:

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

Good news.  If you don't want to commit it could you dump us a copy?  We're
doing this without JMS or MX at the moment, thus no back end decoupling (and
no scalability)...

> 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)? ).

We've been bouncing around this problem ourselves.  I think we ended up
implementing a helper class (I'm not doing the coding) with some static
methods to generate the keys for the cases we are interested in: the
generators and the action handlers can thus use the same reference points to
find the key.  In our case there are only three variations on the keys we
need and the input to generate them is well defined, so we can get away with
this, but it wouldn't work in general...  

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

We have one use case where we have a simple dependency chain that needs to
be invalidated but it can be hard coded as generating the two separate keys
(and flipping the appropriate validity objects to report false).  I had been
thinking that a generalization would use a map (of keys and respective
validity objects) to track which validity objects needed attention, but a
simple chain of dependencies would be simpler.  Haven't really thought about
it much, but in general couldn't it be a one to many dependency mapping (ie;
because of pipeline aggregation)?

> What do others think?
I'll forward this on to the guy doing the coding and see if he has anything
to add...

View raw message