hi martijn On Wed, Jun 10, 2009 at 8:46 AM, Martijn Hendriks<marti...@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.guggisb...@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<marti...@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: marti...@gx.nl >> > >> > Wijchenseweg 111 >> > 6538 SW Nijmegen >> > http://www.gx.nl/ >> > >> > >> > >
