jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [jr3] Tree model
Date Mon, 05 Mar 2012 12:40:17 GMT

On Mon, Mar 5, 2012 at 10:51 AM, Marcel Reutegger <mreutegg@adobe.com> wrote:
>> I'm OK with that tradeoff. Basically we're saying that child nodes are
>> both ordered (in some stable order) *and* orderable (in that they can
>> be explicitly ordered). This means that the MK implementation must
>> store explicit ordering information for nodes, which can be a bit
>> costly for large nodes, as you mention below.
> I'm not sure this is really about the cost. I rather have concerns
> about contention and conflicts in the distributed case.

That's a part of the cost I was thinking of. This clearly is a
significant design decision to make, which is why I'd hope to see some
actual numbers to back us (it would have been great if the existing
prototypes had already provided such detail). Alternatively, we could
leave the orderability issue undefined for now, and revisit the
decision once we have a better idea of what works and what doesn't.

On a related note, I think it would be useful to tie orderability and
SNSs together, as any code that implements SNSs should fairly easily
be able to give us orderability as well. Thus I think it would be a
good solution to implement both either below or above the MK level.
Splitting the features across the MK line doesn't seem that useful.


Jukka Zitting

View raw message