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 Thu, 11 Jun 2009 12:09:44 GMT
Hi Stefan,

There's now a separate issue for the references issue: https://issues.apache.org/jira/browse/JCR-2138.
"Silently merging" is probably a wrong choice of words; the proposed solution lets the last
saving thread overwrite the property. This is just like it used to work; the only difference
is that now the backreferences created by the first thread are reverted.

Best regards,
Martijn


> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Sent: Wednesday, June 10, 2009 11:06 AM
> To: dev@jackrabbit.apache.org
> Subject: Re: Inconsistencies in the repository
> 
> 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