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