jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: [RT] Adding event interface to jackrabbit api
Date Mon, 07 Jul 2008 23:14:03 GMT

On Thu, Jul 3, 2008 at 4:07 PM, Carsten Ziegeler <cziegeler@apache.org> wrote:
> when a repository cluster is used, it seems that a common problem many
> people have is to detect if an observation event is send because of changes
> on the local instance or a remote instance of the cluster.

Clustering should generally be transparent to client applications, so
I'm a bit concerned about adding functionality like this.

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.

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.

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.


Jukka Zitting

View raw message