jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Hendriks <marti...@gx.nl>
Subject RE: Inconsistencies in the repository
Date Wed, 10 Jun 2009 06:46:45 GMT
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?

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

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