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
--
Carsten Ziegeler
[EMAIL PROTECTED]
