Community
Participate
Working Groups
Build Identifier: 4.0 Clone of bug 315407 (3.0) Commit 1 adds a reference to object X. Commit 2 detaches X. Both can happen at the same time when the commits arrive at the server, so no client logic can detect and prevent this scenario. Reproducible: Always
Created attachment 175040 [details] Testcase Testcase which shows that it is possible to lock detached target objects. I confirm to 1) The number of lines that you changed is smaller than 250. 2) You are the only author of these changed lines. 3) You apply the EPL to these changed lines.
In your test case, why do you disable passive updates? Is that somehow relevant? I think that your test logic does *not* imply any concurrency issue because the two commits happen sequentially. Tx1 first detaches the contained element and only after that commit was successful tx2 adds a cross reference to this element. Investigating why this second commit does not produce a server exception...
The problem was that locking in the server is generally a "transient" operation, i.e. the "thing" that is actually locked is either a CDOID or a CDOIDAndBranch, but not a CDORevision. Hence it was possible to lock detached objects. I've fixed that with an additional "persistent" existance check after all locks have been acquired. Committed to HEAD
Martin, let us discuss whether this issue is alo relevant for containment cycle detection...
(In reply to comment #2) > In your test case, why do you disable passive updates? Is that somehow > relevant? > > I think that your test logic does *not* imply any concurrency issue because the > two commits happen sequentially. Tx1 first detaches the contained element and > only after that commit was successful tx2 adds a cross reference to this > element. Investigating why this second commit does not produce a server > exception... I disabled the passive updates in order to simulate concurrent commits. The invalidation of the removal of contained_1 whould have removed the reference nonContainer_2.setElement(contained_2); on transaction 2.
Interesting idea ;-)
Reopening due to the following scenario: A: container B: referencer C: contained in A if C is removed from A & B the commit fails because the xRef check does not check the deltas. That is the xRef code sees that B still references C and therefore permits deleting C. I'll attach a testcase and a fix.
Created attachment 175715 [details] patch for testcase Bugzilla_320690_Tests
For attachment 175715 [details] I confirm to 1) The number of lines that you changed is smaller than 250. 2) You are the only author of these changed lines. 3) You apply the EPL to these changed lines.
Created attachment 175716 [details] Proposed fix. Go through the deltas and check if the found X-Ref is removed.
For attachment 175716 [details] I confirm to 1) The number of lines that you changed is smaller than 250. 2) You are the only author of these changed lines. 3) You apply the EPL to these changed lines.
Created attachment 176101 [details] New patch - for future reference Erwin, thank you for your fix. I had to change it for several reasons and I also fixed the situation that a client deletes an object and adds references to it in the same commit.
Committed to HEAD
Available in R20110608-1407
