Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 64.233.184.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=hAV/mN+4B5tHrO4/hs5OQ1khJ4GhnZEUBMy5/trv7QXpoDM85GfyIsO1y30l/+J7xx
         Fn7xMNw0XnQYNVaLjyq27dTpebB/wabkvxffssYyStrJ0cVhcTZwW+j7FgxiYNWNELNn
         ln6AE9ts23UqzEZnOgyD7K96+T+jt5/ADHQP0=
Message-ID: <510143ac0807071614y1f3ae750lc7b34c64e468e776@mail.gmail.com>
Date: Tue, 8 Jul 2008 02:14:03 +0300
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: dev@jackrabbit.apache.org
Subject: Re: [RT] Adding event interface to jackrabbit api
In-Reply-To: <486CCF28.4090301@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <486CCF28.4090301@apache.org>

Hi,

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.

BR,

Jukka Zitting