jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Revision stability with new MongoMK
Date Wed, 06 Mar 2013 13:10:14 GMT
Hi,

With the current implementation, that's not the case, because revision
stability with multiple cluster nodes isn't implemented yet. The idea is
that each cluster node adds revisions of other cluster nodes to its own
revision list as they are detected. Detection can be eager (when reading a
specific node) or done in a background thread. The background thread isn't
implemented yet as well. I understand the documentation on how this works
exactly is still missing. It simply wasn't a priority so far.

> what needs to be changed higher up in Oak

My plan (so far) was to make this invisible for the higher layers.

Regards,
Thomas



On 3/6/13 1:05 PM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>Hi,
>
>I gave a quick look at the new MongoMK prototype code, and was
>wondering about the guarantees it gives on the stability of revisions.
>More specifically, will the following assertion always hold?
>
>    String r = mk.getHeadRevision();
>    assert mk.getNodes("/", r, 0, 0, -1, null).equals(mk.getNodes("/",
>r, 0, 0, -1, null));
>
>In other words, can we expect a repository revision to remain stable over
>time?
>
>The reason I'm asking is that it looks like two cluster nodes A and B
>could be concurrently adding new nodes in a way that A finishes its
>commit first, returning revisionA, and B following with revisionB. In
>a case where B's clock is behind A's or B's cluster ID is smaller than
>A's it would appear that revisionB came before revisionA, and thus if
>the mk.getHeadRevision() returned revisionA it could be that the first
>getNodes() call returned the state before revisionB was persisted and
>the second one after that happened, resulting in the two returned JSON
>strings being different.
>
>Is this the intended behaviour? If yes, what needs to be changed
>higher up in Oak to prevent this from causing problems (lost
>observation events, missing index updates, etc.)?
>
>BR,
>
>Jukka Zitting


Mime
View raw message