jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Marth <mma...@adobe.com>
Subject Re: [jr3] implicit assumptions in MK design?
Date Thu, 01 Mar 2012 13:53:15 GMT
Hi Dom,

> Are you suggesting, that cluster sync will be provided purely by the underlying NoSQL

Yes, that's what I meant.


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

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

> Hi Michael,
> Are you suggesting, that cluster sync will be provided purely by the underlying NoSQL
database? Until now, I always assumed that all cluster nodes expose 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.
> Regards
> Dominique
> On Mar 1, 2012, at 1:53 PM, Michael Marth wrote:
>> Hi,
>> I have thought a bit about how one could go about implementing a micro kernel based
on a NoSQL database (think Cassandra or Mongo) where a JCR node would probably be stored as
an individual document and the MK implementation would provide the tree on top of that. Consider
that you have two or more cluster nodes of such an NoSQL db (each receiving writes from a
different SPI) and that these two cluster nodes would be eventually consistent.
>> It is easy to imagine cases where the tree structure of one node will be temporarily
broken (at least for specific implementations, see example below). I am not particularly worried
about that, but I wonder if the MK interface 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
version of the tree the MK exposes to the SPI is stable over time (or: can it be the case
that the SPI refreshes the current version it might see a different tree. Again, example below)?
>> I think we should be explicit about these assumptions or non-assumtptions because
either the MK implementer has to take care of them or the higher levels (SPI, client) have
to deal with them.
>> Michael
>> (*) example from above: consider node structure /a/b/c. On on cluster node 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 cluster node could receive the deletion of b
first. So for some time there would be a JCR node c on cluster node 2 that has no parent.
>> example regarding tree version stability: suppose in the example above that tree
version 1 is /a/b/c and tree version 2 is /a. Because deleting b and c will arrive on cluster
node 2 as separate events there must either be some additional communication between the cluster
nodes so that cluster node 2 knows when tree version 2 is fully replicated. Or cluster node
2 will expose 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)

View raw message