|
| Re: [EMF Transaction] Exception during rollback [message #1704885 is a reply to message #1704201] |
Mon, 10 August 2015 12:26   |
|
Hi, Alain,
Indeed, the transaction will have difficulty rolling back if the
ChangeDescription cannot successfully be applied. However, a
ChangeDescription records only changes that actually are effected in
the model. I don't know how it could record changes that haven't yet
occurred.
Does your model have custom implementations of some of these list
features, as UML2 does, that perhaps coordinate changes with other
features? Could it be that undoing some changes causes side-effects in
others that then invalidate changes recorded in those?
Or are there non-ChangeDescription-based commands being undone by the
transaction that could interfere with ChangeDescriptions?
There's not really much that a transaction can do to validate the
applicability of a ChangeDescription ... it seems to me that it's up to
the model and the commands captured by a transaction to ensure that
undo will happen correctly. Although, perhaps failed rollback could
somehow be handled more gracefully? I'm not sure.
Cheers,
Christian
On 2015-08-08 18:12:21 +0000, Alain Picard said:
> On a number of occasions we have faced some exception during rollback,
> if our code encounters an exception while processing the transaction.
> Here is a very typical example:
>
>
> org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException:
> index=1, size=1
> at org.eclipse.emf.common.util.BasicEList.remove(BasicEList.java:602)
> at
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.doRemove(NotifyingListImpl.java:756)
>
> at
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.remove(NotifyingListImpl.java:707)
>
> at
> org.eclipse.emf.ecore.change.impl.ListChangeImpl.process(ListChangeImpl.java:546)
>
> at
> org.eclipse.emf.ecore.change.impl.ListChangeImpl.apply(ListChangeImpl.java:476)
>
> at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(FeatureChangeImpl.java:701)
>
> at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.process(FeatureChangeImpl.java:611)
>
> at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(FeatureChangeImpl.java:518)
>
> at
> org.eclipse.emf.ecore.change.impl.FeatureChangeImpl.apply(FeatureChangeImpl.java:493)
>
> at
> org.eclipse.emf.ecore.change.impl.ChangeDescriptionImpl.apply(ChangeDescriptionImpl.java:300)
>
> at
> org.eclipse.emf.transaction.util.CompositeChangeDescription.apply(CompositeChangeDescription.java:104)
>
> at
> org.eclipse.emf.transaction.impl.TransactionImpl.doRollback(TransactionImpl.java:570)
>
> at
> org.eclipse.emf.transaction.impl.TransactionImpl.commit(TransactionImpl.java:417)
>
> at
> org.eclipse.emf.transaction.impl.TransactionalCommandStackImpl.doExecute(TransactionalCommandStackImpl.java:70)
>
> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165)
>
> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219)
>
> at
> org.eclipse.emf.emfstore.internal.client.transaction.EMFStoreTransactionalCommandStack.execute(EMFStoreTransactionalCommandStack.java:52)
>
>
>
> This seems to be caused by an attempt to remove an element from a list.
> Debugging here is showing that the rollback is trying to apply the undo
> changes produced by the transaction recorder. But the element that it
> is attempting to remove doesn't exist in the list, and thus the error.
> I suspect that this is because when the initial exception occurred that
> this command had not been executed yet. If that is the case, I would
> expect the rollback to have a way to check for the commands that have
> completed and to reverse them, but to ignore any commands that have
> never completed yet. Is it what I might be saying and what is the
> solution?
>
> I'm adding below portion of the stacktrace that represents the original
> exception that triggered the rollback. This might help a bit in
> understanding the situation.
>
> Caused by: java.lang.ClassCastException: ....
> ...
> at
> com.castortech.util.emf.VersioningUtils.runInCompositeOperation(VersioningUtils.java:83)
>
> at
> org.eclipse.sirius.table.business.internal.dialect.TableDialectServices.refresh(TableDialectServices.java:272)
>
> at
> org.eclipse.sirius.business.internal.dialect.DialectManagerImpl.refresh(DialectManagerImpl.java:106)
>
> at
> org.eclipse.sirius.business.api.dialect.command.RefreshRepresentationsCommand.doExecute(RefreshRepresentationsCommand.java:85)
>
> at
> org.eclipse.emf.transaction.RecordingCommand.execute(RecordingCommand.java:135)
>
> at
> org.eclipse.emf.common.command.CompoundCommand.execute(CompoundCommand.java:261)
>
> at
> org.eclipse.sirius.business.internal.session.SessionEventBrokerImpl$PreCommitPriorityNotifyListenersCommand.launchCommands(SessionEventBrokerImpl.java:251)
>
> at
> org.eclipse.sirius.business.internal.session.SessionEventBrokerImpl$PreCommitPriorityNotifyListenersCommand.doExecute(SessionEventBrokerImpl.java:242)
>
> at
> org.eclipse.emf.transaction.RecordingCommand.execute(RecordingCommand.java:135)
>
> at
> org.eclipse.emf.transaction.util.TriggerCommand.execute(TriggerCommand.java:113)
>
> at
> org.eclipse.emf.transaction.impl.TransactionalCommandStackImpl.executeTriggers(TransactionalCommandStackImpl.java:218)
>
> at
> org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl.precommit(TransactionalEditingDomainImpl.java:712)
>
> at
> org.eclipse.emf.transaction.impl.TransactionImpl.commit(TransactionImpl.java:414)
>
> at
> org.eclipse.emf.transaction.impl.TransactionalCommandStackImpl.doExecute(TransactionalCommandStackImpl.java:70)
>
> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165)
>
> at
> org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219)
>
> at
> org.eclipse.emf.emfstore.internal.client.transaction.EMFStoreTransactionalCommandStack.execute(EMFStoreTransactionalCommandStack.java:52)
>
>
>
> Thanks
> Alain
|
|
|
|
| Re: [EMF Transaction] Exception during rollback [message #1704927 is a reply to message #1704888] |
Mon, 10 August 2015 19:08 |
|
Hi, Alain,
Indeed, adapters that automatically manipulate features in response to
changes in other features can definitely interfere with the change
recording and description application mechanism. This is very like
what, for example, superset/subset lists in UML2 do: updates in one
feature are synchronized immediately with other features.
The problem is that the change recorder will record all of the changes
to all of the features, and will expect that when it applies the
inverse of those changes, that it will be the only agent of change in
the model. Side effects that pre-empt "undo" changes that the
ChangeDescription has yet to make will break it.
The UML2 project deals with this by actually providing a custom
implementation of the ChangeRecorder for its editing domain. This
custom ChangeRecorder creates change records that are aware of the
superset/subset relationships between various features and so can deal
with them appropriately.
So, either you will need your adapters to be able to know somehow to
turn off their synchronization when a ChangeDescription is being
applied, or you would have to customize the ChangeRecorder in the same
way that UML2 has done. There aren't many alternatives.
HTH,
Christian
On 2015-08-10 12:37:41 +0000, Alain Picard said:
> Thanks Christian for the info.
> While I know we don't have any list extensions, we do have some pretty
> involved extensions to eNotify in some model elements implementation to
> "convert" some transient relations into some managed "real" relations.
>
> Can you explain a bit more about what are the gotchas that we should be
> watching for and if you have any insight about best practices in this
> area.
>
> Thanks
> Alain
|
|
|
|
Powered by
FUDForum. Page generated in 0.03292 seconds
] 
Search
Help
Register
Login
Home
