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:[email protected]] > Sent: Wednesday, June 10, 2009 11:06 AM > To: [email protected] > Subject: Re: Inconsistencies in the repository > > hi martijn > > On Wed, Jun 10, 2009 at 8:46 AM, Martijn Hendriks<[email protected]> > 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:[email protected]] > >> Sent: Monday, June 08, 2009 5:14 PM > >> To: [email protected] > >> Subject: Re: Inconsistencies in the repository > >> > >> hi martijn > >> > >> > >> On Mon, Jun 8, 2009 at 4:17 PM, Martijn Hendriks<[email protected]> > 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: [email protected] > >> > > >> > Wijchenseweg 111 > >> > 6538 SW Nijmegen > >> > http://www.gx.nl/ > >> > > >> > > >> > > >
