Hi Dom, > Are you suggesting, that cluster sync will be provided purely by the > underlying NoSQL database?
Yes, that's what I meant. 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) >
