jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [RT] Adding event interface to jackrabbit api
Date Tue, 08 Jul 2008 06:00:16 GMT
Jukka Zitting wrote:
> Clustering should generally be transparent to client applications, so
> I'm a bit concerned about adding functionality like this.
Yes, in general it should be transparent.

> What's the use case? The most relevant use case I can come up with is
> a case where multiple copies of the "same" event listener is
> registered for a (clustered) repository by multiple (clustered)
> instances of a client application. Then it would be nice if an event
> would be handled by only one instead of all of those listeners.
Yes, that's exactly the use case - and the use cases I know of always do 
post processing of data.

> Instead of making this coordination a task for the listeners (checking
> of the proposed isLocal() flag), how about if we pushed that
> responsibility to the repository? If, during registration, an event
> listener could be marked as a part of a special clustered set of
> listeners, then the repository could make sure that a matching event
> is only delivered to a single listener in that set. The nice thing
> about this is that as a general solution it doesn't even need to be
> clustering-related, it would work equally well for a single server
> that may serve multiple copies of the same client.
I'm not sure which solution is the "nicer" one :) Both solutions work in 
each scenario. The fact is that today people cast the event to EventImpl
and use this method. That's where I got the idea from.

> Doing that in the general case might be a bit tricky, but a simpler
> version of the same idea would be for example to define a
> LocalOnlyEventListener extension interface for event listeners that
> should only be notified of locally (on the same cluster node)
> initiated changes.
Works for me as well.


Carsten Ziegeler

View raw message