| [CDO] Error in CDOTransactionImpl.postCommit() when modification tracking is enabled [message #1016220] |
Tue, 05 March 2013 14:39  |
Eclipse User |
|
|
|
Hi Eike,
I encounters the following exception when I try to commit a graph of new
objects when CDOResource modifications tracking is enabled
(CDOResource.setTrackingModification(true)). This occurs because the map
of new objects in the single CDOSavePoint has not a guaranted order, a
HashMap is used. Sometime in CDOTransactionImpl.postCommit() on new
objects when iterating on new objects to call CommitTransition, a
CommitTransition is done on a new object before calling it on its
container new object. And at the end of execution of CommitTransition of
the child object, when changing the CDOState to CLEAN, the
CleanObjectHandler, from the modifications tracking, is called which has
the effect to try to resolve the container object of this child through
the "isContained(object)" call but the CDOView objects map has the
container with its temporary CDOID not yet the new one like the
CommitTransition has not been yet called for the container.
We have seen 2 possible fix:
1. use a LinkedHashMap to have predictable iteration order
2. in CDOTransactionImpl.postCommit() do the CDOID remapping before
calling the CommitTransition to avoid have
AbstractCDOView.getObject(CDIID, loadOnDemand) creates new CDOObject
I haven't success to create a JUnit test for that, but I believes that
you understand the issue.
Caused by: java.lang.IllegalArgumentException:
revision=Diagram@OID258:0v1, created=2013-03-01 15:21:00.873,
revised=2013-03-01 15:21:00.872
at
org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.setRevised(BaseCDORevision.java:363)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.addRevision(CDORevisionManagerImpl.java:423)
at
org.eclipse.emf.internal.cdo.view.CDOStateMachine$CommitTransition.execute(CDOStateMachine.java:806)
at
org.eclipse.emf.internal.cdo.view.CDOStateMachine$CommitTransition.execute(CDOStateMachine.java:1)
at
org.eclipse.net4j.util.fsm.FiniteStateMachine.process(FiniteStateMachine.java:162)
at
org.eclipse.emf.internal.cdo.view.CDOStateMachine.commit(CDOStateMachine.java:398)
at
org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl$CDOCommitContextImpl.postCommit(CDOTransactionImpl.java:2248)
at
org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl$CDOCommitContextImpl.postCommit(CDOTransactionImpl.java:2125)
at
org.eclipse.emf.internal.cdo.transaction.CDOSingleTransactionStrategyImpl.commit(CDOSingleTransactionStrategyImpl.java:99)
at
org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:914)
Best Regards.
|
|
|
| Re: [CDO] Error in CDOTransactionImpl.postCommit() when modification tracking is enabled [message #1016671 is a reply to message #1016220] |
Thu, 07 March 2013 10:14  |
|
Am 05.03.2013 15:39, schrieb Esteban DUGUEPEROUX:
> Hi Eike,
>
> I encounters the following exception when I try to commit a graph of new objects when CDOResource modifications
> tracking is enabled (CDOResource.setTrackingModification(true)). This occurs because the map of new objects in the
> single CDOSavePoint has not a guaranted order, a HashMap is used. Sometime in CDOTransactionImpl.postCommit() on new
> objects when iterating on new objects to call CommitTransition, a CommitTransition is done on a new object before
> calling it on its container new object. And at the end of execution of CommitTransition of the child object, when
> changing the CDOState to CLEAN, the CleanObjectHandler, from the modifications tracking, is called which has the
> effect to try to resolve the container object of this child through the "isContained(object)" call but the CDOView
> objects map has the container with its temporary CDOID not yet the new one like the CommitTransition has not been yet
> called for the container.
>
> We have seen 2 possible fix:
> 1. use a LinkedHashMap to have predictable iteration order
> 2. in CDOTransactionImpl.postCommit() do the CDOID remapping before calling the CommitTransition to avoid have
> AbstractCDOView.getObject(CDIID, loadOnDemand) creates new CDOObject
>
> I haven't success to create a JUnit test for that, but I believes that you understand the issue.
It took me a while :P
Please submit a bugzilla for this bug.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
>
> Caused by: java.lang.IllegalArgumentException: revision=Diagram@OID258:0v1, created=2013-03-01 15:21:00.873,
> revised=2013-03-01 15:21:00.872
> at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.setRevised(BaseCDORevision.java:363)
> at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.addRevision(CDORevisionManagerImpl.java:423)
> at org.eclipse.emf.internal.cdo.view.CDOStateMachine$CommitTransition.execute(CDOStateMachine.java:806)
> at org.eclipse.emf.internal.cdo.view.CDOStateMachine$CommitTransition.execute(CDOStateMachine.java:1)
> at org.eclipse.net4j.util.fsm.FiniteStateMachine.process(FiniteStateMachine.java:162)
> at org.eclipse.emf.internal.cdo.view.CDOStateMachine.commit(CDOStateMachine.java:398)
> at
> org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl$CDOCommitContextImpl.postCommit(CDOTransactionImpl.java:2248)
> at
> org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl$CDOCommitContextImpl.postCommit(CDOTransactionImpl.java:2125)
> at
> org.eclipse.emf.internal.cdo.transaction.CDOSingleTransactionStrategyImpl.commit(CDOSingleTransactionStrategyImpl.java:99)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:914)
>
> Best Regards.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.46691 seconds
] 
Search
Help
Register
Login
Home
