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 Scalability of JCR observation
Date Fri, 12 Apr 2013 13:35:30 GMT

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 

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.


View raw message