jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: [jr3] implicit assumptions in MK design?
Date Thu, 01 Mar 2012 14:29:11 GMT

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).


On 3/1/12 2:53 PM, "Michael Marth" <mmarth@adobe.com> 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 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
>>> 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