cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: event aware object cache?
Date Wed, 23 Nov 2005 13:03:07 GMT
On 11/23/05, Max Pfingsthorn <> wrote:
> Geoff Howard [] wrote:
> > On 11/21/05, Max Pfingsthorn <> wrote:
> > > Hi Cocooners!
> > >
> > > I have a question: I couldn't find a nice EventAware object
> > cache in Cocoon, the eventcache block only implements the
> > o.a.c.caching.Cache which I need to pass a byte array.
> > Serializing/deserializing is not really an option for me.
> > > What I would like is a (not necessarily persistent)
> > EventAware cache for objects used for form my responses of a
> > generator. I could imagine that this sort of cache might be
> > useful for others as well. If so, and it is not implemented
> > yet, I would like to go ahead and do so.
> > >
> > > WDYT? Does anyone have any pointers for me?
> >
> > Hmm, it's been a while since I've looked at this and the code base WRT
> > the Cache/Store code has changed since in a way I didn't keep fully
> > abreast of.  The original intention of the EventAware code was to do
> > exactly what you wanted.  IIRC the Cache used to have a transient
> > front-end backed by a persistent backend transparently.  Since then
> > the terminology and code was changed I think to have Stores be
> > transient and Cache persistent.
> I see, so your suggestion would be to implement an EventAware MRUMemoryStore? And maybe
also make the EHDefaultStore  EventAware?
> I guess for that, an "EventAwareManager" would be required cause right now the JMSEventMessageListener
looks up the EventAware cache by itself instead of getting a list of EventAwares and calling
processEvent on them.
> One big problem though: Stores are deprecated... :(

I missed the deprecation of the Stores discussion. Do you have some
pointers in the dev list archives?

Would it be sufficient to configure JMSEventMessageListener with a
list of EventAwares?  If the EAManager is necessary, I guess it would
have to be configured with such a list unless you can think of a way
for it to discover all EventAwares in the system?

> > For your need, it may only be necessary to factor the relevant code
> > out of the Cache to a more generic place where both Store and Cache
> > can take advantage of it.
> Not sure if that is necessary. I can see that the functionality is rather the same, but
making a wrapper around the ehcache Cache or something like that seems a little weird cause
we would dictate which cache implementation to use.
> Maybe the EventAware interface is enough, but add a manager for them?
> I guess we could provide ready wrappers around different implementations, WDYT?
> > I can't give it a lot of time at the moment, but do want to help make
> > sure this is generally useful.  Can you provide some more details of
> > the problem as it exists now to help me get up to speed quickly?
> My problem is that I need to generate xml ( obviously ;) ), but the xml tree represents
a directory tree on a webdav server. So, I don't need to walk over all collections to generate
my xml, just over the ones that changed. For that, I'd like to keep two things in memory:
A list of children per node and a set of attributes per node. These might not be Serializable
(right now I just stuff the AttributesImpl object into a map)...
> So, what I want is a way to remove these two from the cache/store if a corresponding
event comes in so they are regenerated, but I don't have to rebuild the complete structure.
> Another usecase in favor of having a general EventAwareManager to keep track of EventAware
instances would be to have a way to notify a business object model when the backend changes,
or generally notify it via JMS. We'll be running into that soon over here, so it would be
nice to get some ground work done.

That is outside the original intention but should work.  There may be
some odd block dependencies if someone wants to do that but not use an
EventAwareCache, they could wind up requiring both the JMS block and
the EventAware block anyway.  If you can see a way to allow your
use-case but avoid that false dependency, that'd be great.


View raw message