I have been debugging this a bit and the (or a) difference between the cases that work and those that fail pop up in CommitManager.commitNewObjectsForClassWithChangeSet
There is a loop over an enumeration created with newObjectChangesList.elements() but the order in which the two new Node objects are returned is not stable.
For the cases that fail, the node "/d/d/d/" is returned first (while it is the second the app inserts). This not only seems to trigger an insert of that node but, as it is the parent, also of "/d/d/". For some reason that makes Toplink think in subsequent processing that "/d/d/" is changed somehow.
The cases that succeed first get the "/d/d/" node from the enumeration of newObjectChangesList
I am at loss whether the order of the enumeration should respect the insert order, or whether the processing in the case "/d/d/d/" is returned first goes astray somewhere.
I do tend to think this is a Toplink problem.
Any suggestions on how I could work around this, or fix the issue, are most warmly welcomed!
Thanks,
Peter
[Message sent by forum member 'pgp_coppens' (pgp_coppens)]
http://forums.java.net/jive/thread.jspa?messageID=246666