[jr3] implicit assumptions in MK design?

[Michael Marth <mm...@adobe.com>]

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)

Re: [jr3] implicit assumptions in MK design?

[Stefan Guggisberg <st...@gmail.com>]

On Thu, Mar 1, 2012 at 2:53 PM, Michael Marth <mm...@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.

well that's one possible approach.

cheers
stefan

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

Re: [jr3] implicit assumptions in MK design?

[Thomas Mueller <mu...@adobe.com>]

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" <mm...@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 
>
>
>--
>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
>>>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)
>> 
>

Re: [jr3] implicit assumptions in MK design?

[Michael Marth <mm...@adobe.com>]

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

Re: [jr3] implicit assumptions in MK design?

[Dominique Pfister <dp...@adobe.com>]

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)

Re: [jr3] implicit assumptions in MK design?

[Michael Dürig <md...@apache.org>]

Hi,

I thinks this is a very important aspect to keep in mind. As I said 
already [1], having inconsistencies on a given layer might result in 
inconsistencies on upper layers. It is therefore important to have a 
clear picture on what these inconsistencies are, how they propagate and 
how to handle them. "Clients may not make any consistency assumptions" 
as we have it currently on the list of our goals [2] is too weak as 
Jukka also already mentioned.

Michael

[1] 
https://docs.google.com/presentation/pub?id=131sVx5s58jAKE2FSVBfUZVQSl1W820_syyzLYRHGH6E&start=false&loop=false&delayms=3000#slide=id.g42c68a5_0_0

[2] 
http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackrabbit%203


On 1.3.12 12:53, 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)