On Thu, Mar 1, 2012 at 2:53 PM, Michael Marth <[email protected]> wrote: > Hi Dom, > >> Are you suggesting, that cluster sync will be provided purely by the >> underlying NoSQL database? > > Yes, that's what I meant.
well that's one possible approach. cheers stefan > > Michael > > > -- > Michael Marth | Engineering Manager > +41 61 226 55 22 | [email protected] > 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) >> >
