Comment 1 Esteban DUGUEPEROUX 2012-03-15 12:49:59 EDT

Created attachment 212736 [details]
JUnit test

Attached a JUnit test to show the issue using a metamodel also in attachment.

Comment 2 Esteban DUGUEPEROUX 2012-03-15 12:50:48 EDT

Created attachment 212737 [details]
The metamodel

Comment 3 Esteban DUGUEPEROUX 2012-03-15 13:00:46 EDT

Reproduced with CDO 4.0 SR2 but also with master.

Comment 4 Esteban DUGUEPEROUX 2012-03-15 13:04:55 EDT

If we doesn't set CDOSavePoint we doesn't have the exception, this seems related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=352977 .

Comment 5 Esteban DUGUEPEROUX 2012-03-21 06:01:03 EDT

Removing the "childRoot" model element from its resource before adding to the new resource doesn't throws exception.

Comment 6 Eike Stepper 2012-03-21 06:09:17 EDT

I regenerated model6 with containmentProxies=true and stripped down the test to the minimum to reproduce the problem:

    Root root = getModel6Factory().createRoot();
    BaseObject childRoot = getModel6Factory().createBaseObject();
    root.getListA().add(childRoot);

    CDOSession session = openSession();
    CDOTransaction transaction = session.openTransaction();
    CDOResource mainResource = transaction.createResource(getResourcePath("/mainResource.model1"));
    mainResource.getContents().add(root);
    transaction.commit();

    // Control childRoot to a new resource
    CDOResource fragmentResource = transaction.createResource(getResourcePath("/fragmentResource.model1"));
    fragmentResource.getContents().add(childRoot);
    transaction.commit();

    // Uncontrol category1 to its original resource
    fragmentResource.getContents().remove(childRoot);
    transaction.setSavepoint(); // <---- Problem here!!!
    transaction.commit();

    // Control again childRoot to the new resource
    fragmentResource.getContents().add(childRoot);
    transaction.commit();

It turns out that a single setSavepoint() call causes the problem. Removing it makes the test pass.

Comment 7 Eike Stepper 2012-03-21 06:38:00 EDT

The problem is, again, this pathological combination of reattachment with multiple savepoints.
It seems I can fix it with this code in CDOSavepointImpl.getAllRevisionDeltas():

        Set<CDOID> reattachedObjects = savepoint.getReattachedObjects().keySet();
        for (CDOID detachedID : savepoint.getDetachedObjects().keySet())
        {
          if (!reattachedObjects.contains(detachedID))
          {
            allRevisionDeltas.remove(detachedID);
          }
        }

As you've suggested in comment 4 this is really related to bug 352977 which requires a larger redesign to give us more confidence.

Comment 8 Eike Stepper 2012-03-21 06:41:21 EDT

Comment on attachment 212736 [details]
JUnit test

Esteban, please confirm that:

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.

Comment 9 Eike Stepper 2012-03-21 06:55:26 EDT

All suites pass.

commit b255e7b5c36e07a796b294447d0caee8460a79e0

Comment 10 Eike Stepper 2012-03-21 06:56:12 EDT

Port to 4.1 via bug 374882.

Comment 11 Eike Stepper 2012-03-21 07:23:02 EDT

Created attachment 212989 [details]
Patch

Comment 12 Esteban DUGUEPEROUX 2012-03-21 08:05:03 EDT

I confirm that:

1) The number of lines that I changed is smaller than 250.
2) I am the only author of these changed lines.
3) I apply the EPL to these changed lines.

Thanks.

Comment 13 Eike Stepper 2012-09-21 06:51:26 EDT

Closing.