Comment 1 Eike Stepper 2011-09-19 03:02:38 EDT

Hi Ronald, the build number doesn't help me to find out the branch and time of the code that produces this issue. And the stack trace matches neither trunk nor 4.0-maintenance. Can you please try to provide a stack trace that results from new integration builds ( http://www.eclipse.org/cdo/downloads/index.php#integration ) or maintenance builds ( http://www.eclipse.org/cdo/downloads/index.php#maintenance )?

Comment 2 Per Sterner 2012-07-31 07:17:16 EDT

I am not sure if we have the same problem, but we have a 'similar' stack trace. The problem 'only' occured here, if we have set the range option.

org.eclipse.emf.cdo.util.CommitException: Rollback in DBStore: java.lang.NullPointerException
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AuditListTableMappingWithRanges.objectDetached(AuditListTableMappingWithRanges.java:530)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalClassMapping.detachObject(AbstractHorizontalClassMapping.java:730)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.detachObjects(DBStoreAccessor.java:618)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.spi.server.StoreAccessor.doWrite(StoreAccessor.java:89)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.spi.server.StoreAccessorBase.write(StoreAccessorBase.java:149)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:487)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:43)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.spi.server.InternalCommitContext$1.runLoop(InternalCommitContext.java:1)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.net4j.util.om.monitor.ProgressDistributor.run(ProgressDistributor.java:96)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicatingCommit(CommitTransactionIndication.java:262)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.server.internal.net4j.protocol.CommitTransactionIndication.indicating(CommitTransactionIndication.java:96)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:109)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:86)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:92)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.net4j.signal.Signal.doInput(Signal.java:328)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:65)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.net4j.signal.Signal.runSync(Signal.java:253)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at java.lang.Thread.run(Thread.java:619)
INFO   | jvm 1    | 2012/07/31 12:49:16 |
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.internal.cdo.transaction.CDOSingleTransactionStrategyImpl.commit(CDOSingleTransactionStrategyImpl.java:85)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1139)
INFO   | jvm 1    | 2012/07/31 12:49:16 |       at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1159)

Comment 3 Eike Stepper 2012-08-14 22:51:21 EDT

Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.

Comment 4 Eike Stepper 2012-08-30 07:40:31 EDT

Because no description has been provided how to reproduce this problem I can only guess that the revision (that is null) has already been deleted. I tried to write a test case that silmulates this situation:

  public void testDetachConcurrently() throws Exception
  {
    String path = getResourcePath("/test1");

    {
      CDOSession session = openSession();
      CDOTransaction transaction = session.openTransaction();
      CDOResource resource = transaction.createResource(path);
      resource.getContents().add(getModel1Factory().createCompany());
      transaction.commit();
      session.close();
    }

    CDOSession session1 = openSession();
    session1.options().setPassiveUpdateEnabled(false);
    CDOTransaction transaction1 = session1.openTransaction();
    CDOResource resource1 = transaction1.getResource(path);
    EList<EObject> contents1 = resource1.getContents();
    contents1.get(0);

    CDOSession session2 = openSession();
    session2.options().setPassiveUpdateEnabled(false);
    CDOTransaction transaction2 = session2.openTransaction();
    CDOResource resource2 = transaction2.getResource(path);
    EList<EObject> contents2 = resource2.getContents();
    contents2.get(0);

    contents1.remove(0);
    transaction1.commit();

    contents2.remove(0);
    transaction2.commit();
  }

But that fails for a different reason. Whenever something gets detached, here through contents1.remove(0), then the container object gets modified, here resource1, and receives an incremented version. Then transaction2.commit() can already not update the same modification of resource2. It seems with passiveUpdates=false your problem can not be simulated.

I need more infos on how to reproduce the issue or you must set a breakpoint and provide me with more infos that may help me to guess further ;-(

Comment 5 Eike Stepper 2013-06-29 12:17:16 EDT

We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2.

Comment 6 Eike Stepper 2015-07-14 02:09:17 EDT

Moving all open bugzillas to 4.5.

Comment 7 Eike Stepper 2016-07-31 00:52:09 EDT

Moving all unaddressed bugzillas to 4.6.

Comment 8 Eike Stepper 2017-12-28 01:10:53 EST

Moving all open bugs to 4.7

Comment 9 Eike Stepper 2019-11-08 02:13:53 EST

Moving all unresolved issues to version 4.8-

Comment 10 Eike Stepper 2019-12-13 12:41:36 EST

Moving all unresolved issues to version 4.9

Comment 11 Eike Stepper 2020-12-11 10:47:07 EST

Moving to 4.13.