jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: Support concurrent node modifications
Date Wed, 04 Oct 2006 07:33:44 GMT
Hi,

I agree. Of course there are other (may be better) ways to achieve the same
without such problems, like using a deeper hierarchy. But the flat hierarchy
is an important use case IMO. Many developers are used to this, and it will
be hard to educate them to do it in a different way. I think it should be
considered to change the implementation to allow fast addition of child
nodes to a node. I'm not sure if this change alone will solve all problems
(may be not).

At the same time, I think the current model of node references should be
changed to allow O(1) time when adding or removing a reference to a node. In
my opinion, the same mechanism could be used for references and for child
nodes.

Current implementation (AFAIK):
- each node has a pointer to the parent node
- the parent node has a list of child nodes, stored as a simple list (BLOB)
- each referenced node has a list of references stored as a simple list
(BLOB)

Proposed change:
- the pointer from child to parent should stay
- list of child nodes per node should be stored as a tree (b-tree or binary
tree)
- the list of references to a node should be stored as a tree as well

The actual b-tree implementation does not need to be in Jackrabbit. When
using databases as persistent manager, it is possible to use a regular
b-tree index for example. This feature may not supported by all persistent
managers.

Thomas


On 10/4/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>
> Hi,
>
> The issue of concurrent node modifications from different sessions not
> being supported has (again) recently been raised. It seems like a
> really useful feature that is only prevented by the limitations of the
> current NodeState implementation. Are there other reasons why we
> couldn't support such modifications?
>
> More fundamentally, I'd be interested in finding out ways to separate
> the parent-child relationship handling from the parent NodeState. The
> current design is the root cause for us not supporting content models
> with unlimited children per node.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message