jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: Observation
Date Thu, 07 Nov 2013 19:34:39 GMT
On 07.11.2013, at 10:44, Jukka Zitting <jukka.zitting@gmail.com> wrote:

> 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).

Observation can't guarantee everything, at some point the application needs to handle that,
e.g. manual refresh option or users simply repeating the task. And I thought we agreed on
removing those nasty cluster events as much as possible :) IMHO this is a place to trade off
100% availability for scalability.

> Commit hooks don't have that problem.

Switching code to commit hooks and making them very Oak dependent is quite an effort, if that's
what you mean. Or do you suggest to implement some similar simple listener mechanism based
on commit hooks (but not forcing applications to write them themselves, coding against the
oak internal API within the listener)?

As mentioned, ideally that new API I propose can be hooked into the existing JCR API with
just an additional listener subtype interface (say in jackrabbit-api) and could be implemented
transparently for Jackrabbit 2 (well, with some utility). Since we say the long-running session
is no issue at all, we don't need a completely separate API to manage that.

> 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.

>From an application perspective, I see it completely opposite :) Cluster events mostly
only apple to core infrastructure (e.g. the code deployment in Sling), but not the high-level
content processing for which observation is great. Those are local by default and are usually
the majority, at least in our CMS environment.

View raw message