Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.219.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAB+dfik3_9cmU3GATL88ZETjWVQT_hZtb6-boG0WtYrYO5LO-w@mail.gmail.com>
References: <33997BDF-F06A-4120-BE72-E41481B5C7EF@adobe.com>
 <CAOFYJNbHabRxv+Q0wkfs6s2Ops6JD3xTSe10ZQS=uUDRrRt5aA@mail.gmail.com>
 <CAB+dfik3_9cmU3GATL88ZETjWVQT_hZtb6-boG0WtYrYO5LO-w@mail.gmail.com>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Thu, 7 Nov 2013 13:44:37 -0500
Message-ID: 
 <CAOFYJNaaHn3RHoiCvN70Qev8i3K0nN_G-pe7KuMwNFN63A1b_A@mail.gmail.com>
Subject: Re: Observation
To: Oak devs <oak-dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Thu, Nov 7, 2013 at 1:12 PM, Tobias Bocanegra <tripod@apache.org> wrote:
> On Thu, Nov 7, 2013 at 5:46 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>> On Wed, Nov 6, 2013 at 8:49 PM, Alexander Klimetschek
>> <aklimets@adobe.com> wrote:
>>> 1) listeners should not get external events by default
>>
>> I'd rather not make such a default. A component designed to process
>> local changes should in most cases be implemented as a commit hook,
>> not an observation listener.
>
> I disagree. the commit hook is executed before the commit - which
> still can fail. Also, the commit hook is highly inconvenient to use.
> what you really want are nicely aggregated observation events :-)

Right, but the local-only observation pattern is structurally flawed,
as it can't guarantee that the events actually do get processed (for
example if the server dies during event delivery). Commit hooks don't
have that problem.

The case where a commit hook would not be applicable is when the
relevant functionality triggers some external changes, for example
sending an email notification. In such cases the local-only
observation pattern is used as a basic cluster synchronization
mechanism for guaranteeing that the event is only processed once
across the cluster. There are other, more reliable ways of doing that.
For example the checkpoint mechanism used by the asynchronous indexer
can guarantee that each change is processed once and only once across
a cluster, even if there are multiple concurrent listeners or if all
of them become unavailable for a while.

AFAICT there's no use case for which the local only -listener pattern
would be the best solution, so while we do need it for backwards
compatibility, it IMHO should not be the default for any new
functionality.

BR,

Jukka Zitting