| [CDO] Error when saving a model having two editors opened [message #1061703] |
Mon, 03 June 2013 10:28  |
Eclipse User |
|
|
|
Hi,
I'm having problems when having multiple CDO editors opened and save one of them. I get an exception that says "java.lang.IllegalStateException: Cannot modify resource set without a write transaction".
In my editors, every one of them is managed by a different CDO Transaction. When creating the editor, a Transactional Editing Domain is assigned, and the resource set is provided by the CDO Transaction.
So in my example, I have 2 editors A and B. Resource A references resource B. And when I save the editor A, CDO tries to refresh the resources in the Transaction of the editor B, having the following exception:
java.lang.IllegalStateException: Cannot modify resource set without a write transaction
at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.assertWriting(TransactionChangeRecorder.java:348)
at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.appendNotification(TransactionChangeRecorder.java:302)
at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.processObjectNotification(TransactionChangeRecorder.java:284)
at org.eclipse.emf.transaction.impl.TransactionChangeRecorder.notifyChanged(TransactionChangeRecorder.java:240)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374)
at org.eclipse.emf.common.notify.impl.NotificationChainImpl.dispatch(NotificationChainImpl.java:98)
at org.eclipse.emf.common.notify.impl.NotificationChainImpl.dispatch(NotificationChainImpl.java:86)
at org.eclipse.emf.internal.cdo.view.CDOViewImpl.sendDeltaNotifications(CDOViewImpl.java:1022)
at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(CDOViewImpl.java:889)
at org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRunnable.run(CDOViewImpl.java:1661)
at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:26)
at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:1)
at org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWorker.java:88)
at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWorker.java:79)
at org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Worker.java:206)
I thing it's no problem of CDO, but mine, but I don't know how to solve it. Any idea?
Thanks,
Marc
|
|
|
|
|
| Re: [CDO] Error when saving a model having two editors opened [message #1061866 is a reply to message #1061710] |
Tue, 04 June 2013 08:35  |
| Eclipse User |
|
|
|
Hi, Marc,
The Kepler release of Papyrus now includes integration with CDO. As it
is based on GMF, Papyrus uses TransactionalEditingDomains with CDO
(with the help of the CDO's Dawn component).
You might have a look at the org.eclipse.papyrus.cdo.* plug-ins for
ideas. These are not included in the main Papyrus installation, but in
the "extra plug-ins" which are available in the SVN repo or installable
via "Help -> Install Additional Papyrus Components".
HTH,
Christian
On 2013-06-03 14:53:27 +0000, Marc Gil said:
> I checked the CDOEditor class from CDO and I realized that Eike is not
> using a Transactional Editing Domain, but an Adapter Factory Editing
> Domain. If I do the same, the error doesn't appear.
>
> There is any reason about Transactional Editing Domains should not work
> properly in CDO? It's better to use Adapter Factory Editing Domains?
>
> Thanks,
> Marc
|
|
|
|
| Re: [CDO] Error when saving a model having two editors opened [message #1706362 is a reply to message #1061879] |
Wed, 26 August 2015 05:35 |
| Eclipse User |
|
|
|
Hi,
I know this is an old thread but the answer might be of value for others. So in short:
You can make use of the
org.eclipse.papyrus.cdo.core.resource.CDOAwareTransactionalEditingDomainProvider
which uses a
org.eclipse.emf.cdo.dawn.transaction.DawnTransactionChangeRecorder
This special ChangeRecorder filters out
org.eclipse.emf.cdo.CDODeltaNotification
which cause the actual problem.
Regards,
Thorsten
|
|
|
Powered by
FUDForum. Page generated in 1.11161 seconds
Home
I was using TransactionalEditingDomains for the same reason, in order to allow GMF integration in CDO in the future, but at the moment it's enough for us to use AdapterFactoryEditingDomain that is using for instance the default CDO Editor.