Hi, On Tue, Jun 19, 2012 at 6:45 AM, Michael Dürig <[email protected]> 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. BR, Jukka Zitting
