Hi, On Thu, Jul 3, 2008 at 4:07 PM, Carsten Ziegeler <[EMAIL PROTECTED]> 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. BR, Jukka Zitting
