Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of mmarth@adobe.com designates
 64.18.1.27 as permitted sender)
From: Michael Marth <mmarth@adobe.com>
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Date: Thu, 1 Mar 2012 13:53:15 +0000
Subject: Re: [jr3] implicit assumptions in MK design?
Thread-Topic: [jr3] implicit assumptions in MK design?
Thread-Index: Acz3sqZ+1ofxImkhTumKMOAPEX2iHQ==
Message-ID: <947F2A67-7520-4C2A-BA61-615F26077855@adobe.com>
References: <D278B36D-0882-47BF-B2C5-E9F7162C9C41@adobe.com>
 <2E8E5970-1EDE-4125-AE70-E5B7D56686FE@adobe.com>
In-Reply-To: <2E8E5970-1EDE-4125-AE70-E5B7D56686FE@adobe.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Dom,

> Are you suggesting, that cluster sync will be provided purely by the unde=
rlying NoSQL database?

Yes, that's what I meant.

Michael=20


--
Michael Marth | Engineering Manager
+41 61 226 55 22 | mmarth@adobe.com
Barf=FCsserplatz 6, CH-4001 Basel, Switzerland

On Mar 1, 2012, at 2:25 PM, Dominique Pfister wrote:

> Hi Michael,
>=20
> Are you suggesting, that cluster sync will be provided purely by the unde=
rlying NoSQL database? Until now, I always assumed that all cluster nodes e=
xpose an MK interface, and that changes are transmitted to other nodes via =
calls on this MK interface. So in your example, cluster node 2 would see a =
"delete /a/b" and the question of a broken tree never arises.
>=20
> Regards
> Dominique
>=20
> On Mar 1, 2012, at 1:53 PM, Michael Marth wrote:
>=20
>> Hi,
>>=20
>> I have thought a bit about how one could go about implementing a micro k=
ernel based on a NoSQL database (think Cassandra or Mongo) where a JCR node=
 would probably be stored as an individual document and the MK implementati=
on would provide the tree on top of that. Consider that you have two or mor=
e cluster nodes of such an NoSQL db (each receiving writes from a different=
 SPI) and that these two cluster nodes would be eventually consistent.
>>=20
>> It is easy to imagine cases where the tree structure of one node will be=
 temporarily broken (at least for specific implementations, see example bel=
ow). I am not particularly worried about that, but I wonder if the MK inter=
face design implicitly assumes that the MK always exposes a non-broken tree=
 to the SPI. The second question I have if we assume that a particular vers=
ion of the tree the MK exposes to the SPI is stable over time (or: can it b=
e the case that the SPI refreshes the current version it might see a differ=
ent tree. Again, example below)?
>>=20
>> I think we should be explicit about these assumptions or non-assumtption=
s because either the MK implementer has to take care of them or the higher =
levels (SPI, client) have to deal with them.
>>=20
>> Michael
>>=20
>> (*) example from above: consider node structure /a/b/c. On on cluster no=
de 1 JCR node b is deleted. In order to implement that in a document db the=
 MK on cluster node 1 would need to separately delete b and c. The second c=
luster node could receive the deletion of b first. So for some time there w=
ould be a JCR node c on cluster node 2 that has no parent.
>=20
>>=20
>> example regarding tree version stability: suppose in the example above t=
hat tree version 1 is /a/b/c and tree version 2 is /a. Because deleting b a=
nd c will arrive on cluster node 2 as separate events there must either be =
some additional communication between the cluster nodes so that cluster nod=
e 2 knows when tree version 2 is fully replicated. Or cluster node 2 will e=
xpose a tree version 2 that first looks like /a/b and later as /a (i.e. the=
 same version number's tree will change over time)
>=20