jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
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 Tue, 19 Jun 2012 17:10:58 GMT

On Tue, Jun 19, 2012 at 6:45 AM, Michael Dürig <mduerig@apache.org> wrote:
> There is nothing which implies "creating" a ChangeSet instance for each
> commit. The change sets are just implicitly there and can be retrieved with
> instances of ChangeSet created on the fly by calling waitForChanges(). So no
> queues. Consumers which use the blocking feature would just process a
> backlog which they'd consume at their own pace. The backlog is *not*
> represented by a queue but by a position (the previous parameter). Just like
> polling only that the call would block if there is no next change set yet.

You need to keep the sequence of events somewhere. Backing it with the
MicroKernel journal is fine, but note that this implies that the
journal might need to be unbounded or that observation listeners that
can't keep up with the rate of incoming changes will start missing
events. Neither seems like a very good alternative.

> My reasoning for this is - as I said earlier - that it allows us to
> implement JCR journals (which has the concept of change sets through the
> persist event) and also allows us to thread through userData and related
> information.

If we do want to support those features then I agree that something
like what you propose is indeed needed. I'm questioning whether we
really do need that information and if we're willing to pay the
potentially heavy scalability and performance price that comes with
tracking all that information.

> In the clustered case I'd handle changed from a cluster sync like changes
> from any other session. So to the end user changes occurring due to cluster
> synchronisation do not look any different than changes made by another
> session on the same instance.

How would you order those changes? The keywords are "following" and
"previous" in the javadoc snippet I quoted earlier. You can't simply
treat them as changes that came "after" all local changes before the
cluster sync, unless you're ready to abandon the useful feature of
getTreeAfterChange() of one ChangeSet being the same tree as
getTreeBeforeChange() of the "following" ChangeSet.


Jukka Zitting

View raw message