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: Observation design (Was: svn commit: r1351414 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak: api/ChangeSet.java api/ContentSession.java core/ContentSessionImpl.java)
Date Mon, 18 Jun 2012 19:02:47 GMT


On 18.6.12 18:00, Jukka Zitting wrote:
> Hi,
>
> Nice work pushing this ahead! Some design comments below.
>
> On Mon, Jun 18, 2012 at 9:48 AM,<mduerig@apache.org>  wrote:
>> +    /**
>> +     * Wait for changes to occur at {@code path} in the underlying repository.
>> +     * If {@code previous} is not {@code null} returns the {@link ChangeSet}
>> +     * instance following the one given in {@code previous}.
>> +     *
>> +     * @param path  path to the subtree to watch for changes
>> +     * @param previous  previous {@code ChangeSet} or {@code null}.
>> +     * @param timeout the maximum time to wait in milliseconds
>> +     * @return  the next {@code ChangeSet} or {@code null} if a timeout occurred.
>> +     */
>> +    @CheckForNull
>> +    ChangeSet waitForChanges(String path, ChangeSet previous, long timeout);
>
> I'd rather not introduce a blocking method and a new ChangeSet concept
> for this. Instead, could we implement observation by polling the
> latest state of the tree (or the journal) and using a tree diff to
> deliver JCR-level events?
>
> Ideally I'd make the ObservationManager in oak-jcr simply hook into
> Session.refresh() and use a per-session background thread to
> periodically trigger a new refresh(). Apart from the diff support we
> shouldn't need any extra functionality from Oak API.
>
> Stuff like user data and other event details may need more information
> that's available in the default diff. We should look at whether we
> really do need all that info, and if we do, what's the best way of
> making it available through the Oak API. The cleaner and simpler we
> can keep the Oak API the better.

Yes we could do that. However I think the approach I outlined has a 
number of advantages which outweigh the additional complexity (which is 
minimal btw):

- Observation is made explicit feature wise.

- We can implement the polling approach (using a 0 timeout) but also 
have the option to do blocking. Since this can be directly delegated to 
the Microkernel (waitForCommit) the added complexity for this is minimal.

- With the polling approach we offload more complexity to the consumer 
of the API since one has to decide on a reasonable poll interval which 
might be a difficult trade off between latency and server load.

- ChangeSet is just a container carrying the trees as they where after 
and before the change. So this is very close to the diffing approach you 
describe only a bit more explicit. Also ChangeSet is the place where 
additional information like change set meta data could live. I'm close 
to certain that we will need something along these lines (i.e. userData, 
timestamps, user who initiated that change, session id of the 
originating session).

- The approach aligns neatly with the JCR features: implement 
observation using blocking calls and implement journalling by using non 
blocking calls. Also it aligns neatly with the features of the 
Microkernel: waitForCommit and getRevisionHistory.


Michael

>
> BR,
>
> Jukka Zitting


Mime
View raw message