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 microkernel] Write skew
Date Thu, 01 Dec 2011 14:49:55 GMT

> A test-and-set operation necessarily requires at least some level of
> atomicity which can quickly become a bottleneck for a clustered setup.

Test-and-set is a problem in a clustered 'eventually consistent' model,
that's true. I don't know how test-and-set could be used in that way.

Possibly the easiest solution is that each node modification sets the node
type again (to the expected value) even if the user didn't change it.

But I don't think we should try to increase concurrency of write
operations within the *same* repository because that's not a problem at
all. Jackrabbit 2 is slow for other reasons. In my view, the main problems
for Jackrabbit 2 are:

- the more nodes the slower because of the randomly distributed node ids
- the more open sessions the slower because of internal event processing
- the more child nodes the slower because the list is stored as one unit
- jackrabbit core is slow internally for other reasons we didn't analyze
- indexing everything with Lucene is a performance problem at some point
- in a cluster, writes do not scale as writing is basically synchronized

None of that problems is related to transaction isolation. I'm not saying
we shouldn't try to use MVCC. But it never was a problem that Jackrabbit 2
doesn't use MVCC.



View raw message