Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 359064

Summary: Replacing new list elements with list.set throws DanglingReferenceException
Product: [Modeling] EMF Reporter: Stefan Schedl <stefan.schedl>
Component: cdo.coreAssignee: Eike Stepper <stepper>
Status: CLOSED WONTFIX QA Contact: Eike Stepper <stepper>
Severity: normal    
Priority: P3 CC: pascal.lehmann
Version: 4.1   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Bug Depends on: 312534    
Bug Blocks:    
Attachments:
Description Flags
JUnit-Test
stepper: iplog+
Slightly refactored test as a patch (non-incremental) none

Description Stefan Schedl CLA 2011-09-27 09:36:37 EDT
Build Identifier: 20110916-0149

If I replace a new added object from a cdo managed list, it's results in a DanglingReferenceException exception. Doing the same with List.remove and List.add works fine.  

Reproducible: Always

Steps to Reproduce:
1. see attaced junit test
2.
3.
Comment 1 Stefan Schedl CLA 2011-09-27 09:39:03 EDT
Created attachment 204076 [details]
JUnit-Test

JUnit-Test Case for this bug

I confirm that 
 The number of lines that I changed is smaller than 250.
 I'm  the only author of these changed lines.
 I apply the EPL to these changed lines.
Comment 2 Eike Stepper CLA 2011-09-29 02:42:47 EDT
(In reply to comment #0)
> Build Identifier: 20110916-0149

I can not recognize this build ID. Assuming 4.1.
Comment 3 Eike Stepper CLA 2011-09-29 02:49:29 EDT
I can reproduce the DanglingReferenceException.
Comment 4 Eike Stepper CLA 2011-09-29 03:31:01 EDT
The root cause is not so much an issue with the SetFeatureDelta. It's the preceding AddFeatureDelta that is not removed, i.e. replaced with the SET.

As a consequence the revision delta contains:

CDOFeatureDelta[salesOrders, LIST, list=[
	CDOFeatureDelta[salesOrders, ADD, value=SalesOrder?, index=2], 
	CDOFeatureDelta[salesOrders, SET, value=SalesOrder@oid2, index=2, oldValue=SalesOrder?]
]]

A second problem could be that the oldValue of the SET delta is probably not correct.
Comment 5 Eike Stepper CLA 2011-09-29 03:32:14 EDT
Created attachment 204257 [details]
Slightly refactored test as a patch (non-incremental)
Comment 6 Eike Stepper CLA 2011-09-29 03:33:21 EDT
org.eclipse.emf.cdo.util.DanglingReferenceException: The object "SalesOrder?(org.eclipse.emf.cdo.tests.model1.impl.SalesOrderImpl)" is not contained in a resource
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.provideCDOID(AbstractCDOView.java:924)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.provideCDOID(CDOTransactionImpl.java:2082)
	at org.eclipse.emf.cdo.internal.common.revision.delta.CDOSingleValueFeatureDeltaImpl.writeValue(CDOSingleValueFeatureDeltaImpl.java:86)
	at org.eclipse.emf.cdo.internal.common.revision.delta.CDOSingleValueFeatureDeltaImpl.write(CDOSingleValueFeatureDeltaImpl.java:62)
	at org.eclipse.emf.cdo.internal.common.protocol.CDODataOutputImpl.writeCDOFeatureDelta(CDODataOutputImpl.java:495)
	at org.eclipse.emf.cdo.internal.common.revision.delta.CDOListFeatureDeltaImpl.write(CDOListFeatureDeltaImpl.java:136)
	at org.eclipse.emf.cdo.internal.common.protocol.CDODataOutputImpl.writeCDOFeatureDelta(CDODataOutputImpl.java:495)
	at org.eclipse.emf.cdo.internal.common.revision.delta.CDORevisionDeltaImpl.write(CDORevisionDeltaImpl.java:167)
	at org.eclipse.emf.cdo.internal.common.protocol.CDODataOutputImpl.writeCDORevisionDelta(CDODataOutputImpl.java:490)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CommitTransactionRequest.requestingCommit(CommitTransactionRequest.java:170)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CommitTransactionRequest.requesting(CommitTransactionRequest.java:116)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientRequestWithMonitoring.requesting(CDOClientRequestWithMonitoring.java:91)
	at org.eclipse.net4j.signal.RequestWithMonitoring.requesting(RequestWithMonitoring.java:163)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doExtendedOutput(RequestWithConfirmation.java:117)
	at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:296)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doExecute(RequestWithConfirmation.java:102)
	at org.eclipse.net4j.signal.RequestWithMonitoring.doExecute(RequestWithMonitoring.java:233)
	at org.eclipse.net4j.signal.SignalActor.execute(SignalActor.java:51)
	at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
	at org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalProtocol.java:433)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doSend(RequestWithConfirmation.java:87)
	at org.eclipse.net4j.signal.RequestWithConfirmation.send(RequestWithConfirmation.java:73)
	at org.eclipse.net4j.signal.RequestWithMonitoring.send(RequestWithMonitoring.java:108)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:498)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.commitTransaction(CDOClientProtocol.java:377)
	at org.eclipse.emf.internal.cdo.transaction.CDOSingleTransactionStrategyImpl.commit(CDOSingleTransactionStrategyImpl.java:80)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1102)
Comment 7 Stefan Schedl CLA 2011-09-29 03:51:54 EDT
(In reply to comment #2)
> (In reply to comment #0)
> > Build Identifier: 20110916-0149
> 
> I can not recognize this build ID. Assuming 4.1.

I used the indigo 3.7.1 release, update from 3.7.0.     
The build ids from cdo itself are
CDO Model Repository Server	4.0.0.v20110919-0849	
CDO Model Repository Client	4.0.0.v20110919-0849
Comment 8 Eike Stepper CLA 2011-09-29 05:36:36 EDT
We've discussed possible solutions internally andit's clear that fixing the deltas when they are produced is very complex, even more so when considering multiple savepoints.

On the other hand the entire problem will go away as part of the solution to bug 312534 (will be a bigger effort, awaiting funds) anyway. That and the fact that there's an easy workaround (set=remove+add) are the reasons why we've decided not to spend major efforts here and now.

The best I *could* try is to internally replace the set() implementation by calls to remove() followed by set(). That would probably not leave a SET delta, but I assume nobody would even realize. Is this really really required for you now? If so, please reopen.
Comment 9 Eike Stepper CLA 2011-09-29 05:38:03 EDT
(In reply to comment #8)
> The best I *could* try is to internally replace the set() implementation by
> calls to remove() followed by set().

Correction: remove() followed by add().
Comment 10 Eike Stepper CLA 2012-09-21 07:18:36 EDT
Closing.