jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Scalability of JCR observation
Date Fri, 12 Apr 2013 15:49:01 GMT

See https://issues.apache.org/jira/browse/OAK-775

Michael

On 12.4.13 14:35, Michael Dürig wrote:
> Hi,
>
> Currently JCR observation in Oak is targeted towards scalability and
> therefore compromises on some features:
>
> * Observation events are generated by diffing revisions. This results in
> a consolidated view where intermediated events might have cancelled out
> and the order of events is completely random.
>
> * No support Event.getUserId() and Event.getUserData().
>
> Since this change might create backward compatibility issues for some
> applications, Angela, Marcel, Tom and I came up with the idea to
> implement a 2nd, more backward compatible approach to observation in
> Oak. This approach would in contrast to the former one come with
> compromises in scalability. Clients could choose between the
> implementations when registering an event listener (e.g using a marker
> interface).
>
> An implementation approach for backward compatible observation is to use
> a commit hook to record the required changes to a journal (e.g.
> /jcr:system/rep:observation). Observation listeners would then later
> generate the observation events by scrapping that journal asynchronously.
>
> Such an approach would increase the size of the repository by a constant
> factor < 2 since changes required for observation are also written to
> the journal. Furthermore it adds a somewhat expensive commit hook for
> recording such changes. The idea is that there is no such impact as long
> as backward compatible observation is not used.
>
> A somewhat open question is how this should work across the cluster. The
> best way is probably for cluster sync to exclude the observation journal
> and have the built by each cluster node individually.
>
> Michael

Mime
View raw message