jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: [jr3] MicroKernel prototype
Date Wed, 17 Mar 2010 18:59:41 GMT
Hi Thomas,

results look good! I think it's clear that this is not a final and
fair comparison, but it's good to be able to see which of the missing
features actually makes it more complex and/or slower while they will
be implemented.

On Wed, Mar 17, 2010 at 19:42, Thomas Müller <thomas.mueller@day.com> wrote:
> I'm wondering what is the *most* problematic features to verify the
> architecture:

I have no real answer, but just a prioritization what should be fast
and what not (I reordered the bullet points accordingly):

> - orderable child nodes
> - transactions
> - clustering
> - observation
> - correct path parsing and lookup
> - multiple sessions
> - large number of child nodes (as discussed for jr3)

Core features IMO, must be as fast as possible.

> - same name siblings
> - node types
> - locking

I think the above features should be "optional" and only add
additional computations if used (eg. if a non-nt:unstructured node
type is used, etc.).

> - security

Since this typically has to work on each node/property read, it has a
major impact. However, I guess that it is already quite optimized in
Jackrabbit 2.0.

> - workspaces

Shouldn't impact performance - just like a larger number of total
nodes in a single workspace should not affect performance.

> - search

Lies in-between... the problem with search is the (required ?)
transactionality on writes.

>> cut some features to gian performance improvement.
> I'm not sure. What features could be cut?

None, it should still be fully jcr 2.0 compliant. But as we discussed,
it can deliberately prefer certain use cases.


Alexander Klimetschek

View raw message