jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: Support concurrent node modifications
Date Wed, 04 Oct 2006 09:13:21 GMT
i agree with tobi's statements.

since this is a rather major core change with potential
backward compatibility issues i guess this would be
a candidate for a 2.0 release.

for the time being i created an issue which should significantly
improve the current situation and which should be relatively easy
to implement:
https://issues.apache.org/jira/browse/JCR-584

cheers
stefan

On 10/4/06, Tobias Bocanegra <tobias.bocanegra@day.com> wrote:
> > 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.
>
> this not only a problem of the storage in the persistence manager, but
> rather how the items are layed out in memory. if every node state has
> a list of child node entries, the update will always fail in case of
> concurrent modifications. further, such updates MUST fail in the case
> of ordered child nodes. otherwise the application can't rely on the
> proper ordering of the nodes.
>
> what is needed is a (b)tree representation in the memory which can be
> dynamically loaded, if nodes are missing. and that support concurrent
> hierarchy modifications, especially 'adding a childnode' (which should
> be possible to propagate down to the pm).
>
> how the items are stored in the persistence manager is secondary.
> since at the time the data is stored, the 'consolidated' states are
> already available in the shareditemstatemanager.
>
> the references should probably be stored more finegrained. i.e. the
> following operations should be supported by the 'referencemanager' and
> the respective pms:
>   addReference(source, target)
>   modifyReference(source, target) // could be covered by addReference
>   removeReference(source, target)
>   getReferences(target)
>   getReference(source) // which is optional, since this is stored in
> the property
>
> regards, toby
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>

Mime
View raw message