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 Wed, 10 Jun 2009 09:05:59 GMT
hi martijn

On Wed, Jun 10, 2009 at 8:46 AM, Martijn Hendriks<martijnh@gx.nl> wrote:
> Hi Stefan,
>
> Thanks for your pointer. I've created a unit test for both issues and attached it to
the issue. Furthermore,  I've looked into the SharedItemStateManager.Update. updateReferences
method and I think that the spurious reference issue can be fixed there by removing added
reference properties first if they exist. This silently merges the updates instead of throwing
an exception. What do you think of that?

yes, that would be an option. however, we'll have to have a closer
look at what's happening. silently 'merging' the updates is ok if both
properties have identical values (remember that they could be
multi-valued). otherwise throwing an exception would be more
appropriate.

>
> I think that both issues are not so much related as I initially thought. Shall i create
a new issue for the spurious reference?

yeah, taht would be great.

thanks a lot
stefan

>
> Best regards,
> Martijn
>
>
>> -----Original Message-----
>> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
>> Sent: Monday, June 08, 2009 5:14 PM
>> To: dev@jackrabbit.apache.org
>> Subject: Re: Inconsistencies in the repository
>>
>> 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