Comment 1 Egidijus Vaisnora 2011-02-18 03:24:03 EST

Created attachment 189254 [details]
test case

Comment 2 Caspar D. 2011-03-28 04:43:47 EDT

Problem here is that the PushTransaction fetches affected objects by
CDOID. When the rootResource gets fetched by CDOID, it doesn't get
registered... a bug indeed, methinks. Patch coming up.

Comment 3 Caspar D. 2011-03-28 05:11:00 EDT

Created attachment 191983 [details]
Patch v1 (including testcase)

Fix and a simpler testcase that demonstrates the problem without
using a PushTx.

Comment 4 Caspar D. 2011-03-28 05:39:54 EDT

Hmm... this patch introduces some subtle breakage.

Problem is as follows:

Fetching a resource triggers an iteration over the resources already
in the resourceSet, to compare their URI's with the URI being fetched.
This means getURI gets called on every resource.

This triggers construction of a resource's path, which in turn requires
its 'folder' to be fetched. This folder is its container, which could
be the rootResource. When the rootResource gets fetched (and the patch
for this Bugzilla in place), it gets added to the resources collection
in the resourceSet...

But that's the collection being iterated over, so a ConcurrentModificationEx
gets thrown...

Comment 5 Caspar D. 2011-03-28 06:45:03 EDT

To be more succinct: getting a CDOResource's URI might trigger
the loading of additional resources, and that's problematic if
a collection of resources is being iterated over.

I think it's a weakness in our logic that the loading of additional
resources is necessary just to construct a URI... but changing this
would require modifications to the core model, i.e. to CDOResourceNode.
I'm not sure if that's desirable.

For now, I'll provide a patch containing a workaround that ensures
that the URI's of all resource's in the resourceSet can be constructed
without triggering any further resource loading.

Comment 6 Caspar D. 2011-03-28 06:45:24 EDT

Created attachment 191992 [details]
Patch v2 (including testcase)

Comment 7 Eike Stepper 2011-04-04 03:35:44 EDT

Created attachment 192437 [details]
Patch v3

Comment 8 Caspar D. 2011-04-04 04:40:42 EDT

Committed revision 7578.

Comment 9 Eike Stepper 2011-06-23 03:38:59 EDT

Available in R20110608-1407