Bugzilla – Full Text Bug Listing
| Summary: | [DB] NPE in DBStoreAccessor.detachObjects | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Ronald Krijgsheld <rkrijgsheld> |
| Component: | cdo.db | Assignee: | Stefan Winkler <stefan> |
| Status: | NEW --- | QA Contact: | Eike Stepper <stepper> |
| Severity: | normal | ||
| Priority: | P3 | CC: | Per.Sterner, stefan |
| Version: | 4.13 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Ronald Krijgsheld
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 )? 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) Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. 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 ;-(
We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2. Moving all open bugzillas to 4.5. Moving all unaddressed bugzillas to 4.6. Moving all open bugs to 4.7 Moving all unresolved issues to version 4.8- Moving all unresolved issues to version 4.9 Moving to 4.13. |