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 Tue, 19 Jun 2012 21:45:49 GMT


On 19.6.12 18:10, Jukka Zitting wrote:
> Hi,
>
> 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.

But this is no different with polling not backed by the Microkernel 
journal: when a client takes a long time to digest changes this might 
cause the next poll to be deferred so much that the relevant revisions 
are not available any more.

>
>> 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.

There is a linear order of the events on each cluster node. The order is 
just not the same for all of them. As I said, a cluster sync is just 
viewed as changes applied by any other session. So its all in the journal.

Michael

>
> BR,
>
> Jukka Zitting

Mime
View raw message