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
