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: Inconsistencies in the repository
Date Mon, 08 Jun 2009 15:13:58 GMT
hi martijn


On Mon, Jun 8, 2009 at 4:17 PM, Martijn Hendriks<martijnh@gx.nl> wrote:
> Hi all,
>
> We have quite some trouble with inconsistencies in our repositories. After some digging
I found two scenario's that might result in inconsistent data:
>
> The starting situation is that there are four nodes: /, /A, /A/B and /C
>
> (i) Corrupt parent-child relation
> Thread 1 uses session1 to add node D to node A.
> Thread 2 uses session2 to move /A/B to /A/C.
>
> After saving you might get the situation in which A still refers to B as a child, but
that B is moved to C.
>
> (ii) "Ghost" reference
> Thread 1 uses session1 to add a reference property "ref to B" to C.
> Thread 2 uses session2 to add a reference property "ref to B" to C.
>
> After saving you might get the situation in which two references to B exist. After deletion
of C there still is a "ghost" reference which makes it impossible to remove B due to referential
integrity.
>
> I created https://issues.apache.org/jira/browse/JCR-2129 and have the feeling that the
NodeStateMerger should handle these cases, but I am not sure. If the NodeStateMerger should
fix this, then I am afraid that the ItemState and subclasses need to be changed as well in
order to provide more detailed information on changes. I really want to fix this issue, but
I am not sure whether this is the right way. Any help, feedback or pointers are much appreciated!
Thanks!
>

i was able to reliably reproduce (ii) thanks to your test case (tanks
btw). i don't think it's a NodeStateMerger problem. i guess (i.e.
hope) that it can be fixed locally in SharedItemStateManager.

it's basically about 2 or more threads creating the same property at
the same time.
the 1st thread succeeds and persists the new property (and records the reference
on the target in the case of a REFERENCE property). the next thread enters
the write lock and doesn't realize that his 'new' property had been created
in the mean time (again recording the reference on the target in the case of a
REFERENCE property).

the same issue doesn't appear with nodes new nodes have distinct uuid's.
id's of new property's however may collide.

cheers
stefan

> Best regards,
> Martijn
>
>
> --
>
> Martijn Hendriks
> <GX> creative online development B.V.
>
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: martijnh@gx.nl
>
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/
>
>
>

Mime
View raw message