Hi, Wouldn't this mean the NoSQL solution knows about hierarchy, and about our revision model? I don't know about a NoSQL database that supports either one. So, I don't currently see how this could work, except for trivial cases (very flat hierarchy, only newest revision can be read).
Regards, Thomas On 3/1/12 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. > >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) >> >
