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)
