jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: SegmentNodeStore merge operations
Date Fri, 08 Mar 2013 10:33:24 GMT

On Thu, Mar 7, 2013 at 2:05 PM, Michael Dürig <mduerig@apache.org> wrote:
> Yes I'm also a bit worried about this. Couldn't this lead to cascading
> undos? And further to violation of other application constraints when data
> gets "uncommited"? I think this is a very slippery slope...

The way I see it, the normal case for commits would be to go against
the root journal and thus never encounter this issue.

Unlike with the new MongoMK that automatically can execute
non-conflicting changes in parallel, the SegmentMK would require
explicit configuration when improved concurrency is required. In other
words, I don't think that for example the default configuration of a
SegmentMK cluster should be for each cluster node to have their own
journals. They might, but only if explicitly configured that way based
on an analysis of the application level access patterns.

The reasoning behind this design is that I think the optimistic
locking mechanism should already buy quite a bit of extra performance
for normal deployments, and the remaining cases where even more write
throughput is needed typically have some very specific and tightly
scoped access patterns for which the extra throughput is needed. And
as mentioned in another email, in my experience such access patterns
are seldom conflicting (or come with strict application-level
constraints) and generally resilient against the potential loss of
some small fraction of changes.

Thus in practice I don't see such cascading undos or constraint
violations becoming much of a problem. But that of course depends on
the amount of care put in deciding which operations should be executed
against lower-level journals. That's probably an area where good
documentation/training and more real-world experience will be needed.


Jukka Zitting

View raw message