Home » Modeling » EMF » [CDO/Dawn] Deadlock on accessing CDOView
[CDO/Dawn] Deadlock on accessing CDOView [message #883515] |
Fri, 08 June 2012 17:40 |
Tim Schaefer Messages: 49 Registered: June 2011 Location: Marburg, Germany |
Member |
|
|
Hi,
in my emf model, I have references to other model instances (EReference 'rootEObject' of type EObject). With Dawn I generated a CDO-enabled extension for my diagram editor (GMF).
The nodes in this editor have a button that, when doubleclicked, executes a command which opens a (dawn-generated) wizard. The command has a reference to the semantic element of the node that was clicked.
When the wizard is closed, the rootEObject of the element is set to the root object of the new created model instance.
Unfortunately a deadlock occurs at this moment (when the rootEObject feature of the semantic element is set). I tracked it down to the first line of CDOStoreImpl.get
public Object get(InternalEObject eObject, EStructuralFeature feature, int index) {
synchronized (view)
{
...
}
}
The command works fine in a non-CDO environment, i.e. with workspace resources.
I specialized it to fit to CDO, but the main difference is that a dawn-generated wizard is used instead of a normal EMF-generated one.
I run CDO 4.0 and tested it with 4.1 (no difference). All models involved are CDO native.
Though I don't think it's a bug in CDO, I think it's me not handling CDO's view concept properly. It might be something trivial that I didn't quite understand, I'm sorry if that's the case...
Hope I provided enough information to describe my scenario.
Kind regards,
Tim
|
|
|
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #883707 is a reply to message #883515] |
Sat, 09 June 2012 06:01 |
|
Am 08.06.2012 19:40, schrieb Tim Schaefer:
> Hi,
>
> in my emf model, I have references to other model instances (EReference 'rootEObject' of type EObject). With Dawn I
> generated a CDO-enabled extension for my diagram editor (GMF).
> The nodes in this editor have a button that, when doubleclicked, executes a command which opens a (dawn-generated)
> wizard. The command has a reference to the semantic element of the node that was clicked.
>
> When the wizard is closed, the rootEObject of the element is set to the root object of the new created model instance.
So far what you tell seems Dawn or GMF specific to me. I hope that Martin finds time to understand this.
> Unfortunately a deadlock occurs at this moment (when the rootEObject feature of the semantic element is set). I
> tracked it down to the first line of CDOStoreImpl.get
> public Object get(InternalEObject eObject, EStructuralFeature feature, int index) {
> synchronized (view)
> {
> ...
> }
> }
I'm sure I'd have to reproduce this to understand it. At least I'd need the full stack traces of all threads involved in
the cycle/deadlock. Please turn on "Java -> Show Monitors" in the local view menu of the Debug view. That can help to
find the involved threads.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> The command works fine in a non-CDO environment, i.e. with workspace resources.
> I specialized it to fit to CDO, but the main difference is that a dawn-generated wizard is used instead of a normal
> EMF-generated one.
>
> I run CDO 4.0 and tested it with 4.1 (no difference). All models involved are CDO native.
> Though I don't think it's a bug in CDO, I think it's me not handling CDO's view concept properly. It might be
> something trivial that I didn't quite understand, I'm sorry if that's the case...
>
> Hope I provided enough information to describe my scenario.
>
> Kind regards,
> Tim
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #883762 is a reply to message #883707] |
Sat, 09 June 2012 10:04 |
Tim Schaefer Messages: 49 Registered: June 2011 Location: Marburg, Germany |
Member |
|
|
Hi Eike,
thanks for your reply.
I'm not so experienced in multi-threading, sorry
I enabled "Show Monitors" and I see that the view (transaction) my main thread is waiting for is owned by the thread InvalidationRunner.
Stacktraces below, don't know if it helps.
Regards,
Tim
Thread [main] (Suspended)
waiting for: CDOTransactionImpl (id=367)
owned by: Thread [InvalidationRunner-Transaction 5 [MAIN]] (Running)
CDOStoreImpl.get(InternalEObject, EStructuralFeature, int) line: 177
ExportInterfaceImpl(CDOObjectImpl).dynamicGet(int) line: 492
EStructuralFeatureImpl$InternalSettingDelegateSingleEObjectResolving(EStructuralFeatureImpl$InternalSettingDelegateSingleEObject).dynamicSet(InternalEObject, EStructuralFeature$Internal$DynamicValueHolder, int, Object) line: 2396
ExportInterfaceImpl(BasicEObjectImpl).eDynamicSet(int, EStructuralFeature, Object) line: 1137
ExportInterfaceImpl(ComponentPartImpl).setRootEObject(EObject) line: 135
DawnCreateNewModelPolicy$DawnOpenModelWizardCommand(OpenModelWizardCommand).processResult(EObject) line: 80
DawnCreateNewModelPolicy$DawnOpenModelWizardCommand(OpenMetaModelWizardCommand).doExecuteWithResult(IProgressMonitor, IAdaptable) line: 53
DawnCreateNewModelPolicy$DawnOpenModelWizardCommand(AbstractTransactionalCommand).doExecute(IProgressMonitor, IAdaptable) line: 247
DawnCreateNewModelPolicy$DawnOpenModelWizardCommand(AbstractEMFOperation).execute(IProgressMonitor, IAdaptable) line: 150
DefaultOperationHistory.execute(IUndoableOperation, IProgressMonitor, IAdaptable) line: 513
DiagramCommandStack.execute(ICommand, IProgressMonitor) line: 206
DiagramCommandStack.execute(Command, IProgressMonitor) line: 169
DiagramCommandStack.execute(Command) line: 156
DawnCompositeEditPartFactory$8(GraphicalEditPart).performRequest(Request) line: 1125
SelectEditPartTracker.performOpen() line: 194
SelectEditPartTracker.handleDoubleClick(int) line: 137
SelectEditPartTracker(AbstractTool).mouseDoubleClick(MouseEvent, EditPartViewer) line: 1069
DelegatingDragEditPartsTracker(SelectionTool).mouseDoubleClick(MouseEvent, EditPartViewer) line: 527
SelectionToolEx(SelectionTool).mouseDoubleClick(MouseEvent, EditPartViewer) line: 527
DiagramEditDomain(EditDomain).mouseDoubleClick(MouseEvent, EditPartViewer) line: 231
DomainEventDispatcher.dispatchMouseDoubleClicked(MouseEvent) line: 291
LightweightSystem$EventHandler.mouseDoubleClick(MouseEvent) line: 518
TypedListener.handleEvent(Event) line: 195
EventTable.sendEvent(Event) line: 84
FigureCanvas(Widget).sendEvent(Event) line: 1053
Display.runDeferredEvents() line: 4165
Display.readAndDispatch() line: 3754
Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2701
Workbench.runUI() line: 2665
Workbench.access$4(Workbench) line: 2499
Workbench$7.run() line: 679
Realm.runWithDefault(Realm, Runnable) line: 332
Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 668
PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149
IDEApplication.start(IApplicationContext) line: 123
EclipseAppHandle.run(Object) line: 196
EclipseAppLauncher.runApplication(Object) line: 110
EclipseAppLauncher.start(Object) line: 79
EclipseStarter.run(Object) line: 344
EclipseStarter.run(String[], Runnable) line: 179
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not available
Method.invoke(Object, Object...) line: not available
Main.invokeFramework(String[], URL[]) line: 622
Main.basicRun(String[]) line: 577
Main.run(String[]) line: 1410
Main.main(String[]) line: 1386
Thread [InvalidationRunner-Transaction 5 [MAIN]] (Suspended)
owns: TransactionImpl (id=444)
owns: CDOTransactionImpl (id=367)
waited by: Thread [main] (Running)
waiting for: Object (id=445)
Object.wait(long) line: not available [native method]
Object.wait() line: 485 [local variables unavailable]
ThreadJob.waitForRun(ThreadJob, IProgressMonitor, InternalJob, Thread) line: 272
ThreadJob.joinRun(ThreadJob, IProgressMonitor) line: 199
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 92
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 286
Lock.uiSafeAcquire(boolean) line: 359
DawnDiagramEditingDomainFactory$DawnDiagramEditingDomain(TransactionalEditingDomainImpl).acquire(InternalTransaction) line: 580
DawnDiagramEditingDomainFactory$DawnDiagramEditingDomain(TransactionalEditingDomainImpl).activate(InternalTransaction) line: 508
TransactionImpl.start() line: 204
DawnDiagramEditingDomainFactory$DawnDiagramEditingDomain(TransactionalEditingDomainImpl).startTransaction(boolean, Map<?,?>) line: 424
DawnDiagramEditingDomainFactory$DawnDiagramEditingDomain(TransactionalEditingDomainImpl).runExclusive(Runnable) line: 321
DawnDiagramUpdater.refreshEditPart(EditPart, DiagramDocumentEditor) line: 79
DawnGMFHandler.handleObject(CDOObject) line: 243
DawnGMFHandler.handleViewInvalidationEvent(CDOViewInvalidationEvent) line: 78
DawnGMFHandler(BasicDawnListener).notifyEvent(IEvent) line: 61
Notifier.fireEventSafe(IEvent, IListener[]) line: 136
CDOTransactionImpl(Notifier).fireEvent(IEvent, IListener[]) line: 100
CDOTransactionImpl(CDOViewImpl).fireInvalidationEvent(long, Map<CDOObject,CDORevisionDelta>, Set<CDOObject>) line: 604
CDOTransactionImpl(CDOViewImpl).doInvalidate(CDOBranch, long, List<CDORevisionKey>, List<CDOIDAndVersion>, Map<CDOID,InternalCDORevision>) line: 508
CDOViewImpl$InvalidationRunnable.run() line: 1241
CDOViewImpl$2(QueueRunner).work(Worker$WorkContext, Runnable) line: 26
CDOViewImpl$2(QueueRunner).work(Worker$WorkContext, Object) line: 1
CDOViewImpl$2(QueueWorker<E>).doWork(Worker$WorkContext) line: 81
CDOViewImpl$2(QueueWorker<E>).work(Worker$WorkContext) line: 72
Worker$WorkerThread.run() line: 206
|
|
| | |
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #885177 is a reply to message #883707] |
Tue, 12 June 2012 15:04 |
Martin Fluegge Messages: 141 Registered: July 2009 |
Senior Member |
|
|
Am 09.06.2012 08:01, schrieb Eike Stepper:
> Am 08.06.2012 19:40, schrieb Tim Schaefer:
>> Hi,
>>
>> in my emf model, I have references to other model instances
>> (EReference 'rootEObject' of type EObject). With Dawn I generated a
>> CDO-enabled extension for my diagram editor (GMF).
>> The nodes in this editor have a button that, when doubleclicked,
>> executes a command which opens a (dawn-generated) wizard. The command
>> has a reference to the semantic element of the node that was clicked.
>>
>> When the wizard is closed, the rootEObject of the element is set to
>> the root object of the new created model instance.
> So far what you tell seems Dawn or GMF specific to me. I hope that
> Martin finds time to understand this.
With CDO 4.0 the whole CDO environment was made more thread-safe. I
remember that about a year ago Eike and I were working on a very complex
deadlock issue, which occured since that time. Unfortunately we did not
find a proper solution. Even the Dawn tests were more vulnerable for
deadlocks. I noticed that when closing the CDOSessionView in the runtime
the test became more stable. You could try, if open, to clode this view.
This could give us an additional hint.
Cheers,
Martin
>
>> Unfortunately a deadlock occurs at this moment (when the rootEObject
>> feature of the semantic element is set). I tracked it down to the
>> first line of CDOStoreImpl.get
>> public Object get(InternalEObject eObject, EStructuralFeature feature,
>> int index) {
>> synchronized (view)
>> {
>> ...
>> }
>> }
> I'm sure I'd have to reproduce this to understand it. At least I'd need
> the full stack traces of all threads involved in the cycle/deadlock.
> Please turn on "Java -> Show Monitors" in the local view menu of the
> Debug view. That can help to find the involved threads.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>> The command works fine in a non-CDO environment, i.e. with workspace
>> resources.
>> I specialized it to fit to CDO, but the main difference is that a
>> dawn-generated wizard is used instead of a normal EMF-generated one.
>>
>> I run CDO 4.0 and tested it with 4.1 (no difference). All models
>> involved are CDO native.
>> Though I don't think it's a bug in CDO, I think it's me not handling
>> CDO's view concept properly. It might be something trivial that I
>> didn't quite understand, I'm sorry if that's the case...
>>
>> Hope I provided enough information to describe my scenario.
>>
>> Kind regards,
>> Tim
|
|
| | |
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #886025 is a reply to message #883762] |
Thu, 14 June 2012 04:26 |
|
Am 09.06.2012 12:04, schrieb Tim Schaefer:
> Hi Eike,
>
> thanks for your reply.
> I'm not so experienced in multi-threading, sorry :(
> I enabled "Show Monitors" and I see that the view (transaction) my main thread is waiting for is owned by the thread
> InvalidationRunner.
>
> Stacktraces below, don't know if it helps.
>
>
> Regards,
> Tim
>
>
> Thread [main] (Suspended)
> waiting for: CDOTransactionImpl (id=367)
> owned by: Thread [InvalidationRunner-Transaction 5 [MAIN]] (Running)
> CDOStoreImpl.get(InternalEObject, EStructuralFeature, int) line: 177
> ExportInterfaceImpl(CDOObjectImpl).dynamicGet(int) line: 492
> EStructuralFeatureImpl$InternalSettingDelegateSingleEObjectResolving(EStructuralFeatureImpl$InternalSettingDelegateSingleEObject).dynamicSet(InternalEObject,
> EStructuralFeature$Internal$DynamicValueHolder, int, Object) line: 2396
> ExportInterfaceImpl(BasicEObjectImpl).eDynamicSet(int, EStructuralFeature, Object) line: 1137
> ExportInterfaceImpl(ComponentPartImpl).setRootEObject(EObject) line: 135
> DawnCreateNewModelPolicy$DawnOpenModelWizardCommand(OpenModelWizardCommand).processResult(EObject) line: 80
> DawnCreateNewModelPolicy$DawnOpenModelWizardCommand(OpenMetaModelWizardCommand).doExecuteWithResult(IProgressMonitor,
> IAdaptable) line: 53
> DawnCreateNewModelPolicy$DawnOpenModelWizardCommand(AbstractTransactionalCommand).doExecute(IProgressMonitor,
> IAdaptable) line: 247
> DawnCreateNewModelPolicy$DawnOpenModelWizardCommand(AbstractEMFOperation).execute(IProgressMonitor, IAdaptable)
> line: 150
> DefaultOperationHistory.execute(IUndoableOperation, IProgressMonitor, IAdaptable) line: 513
> DiagramCommandStack.execute(ICommand, IProgressMonitor) line: 206
> DiagramCommandStack.execute(Command, IProgressMonitor) line: 169
> DiagramCommandStack.execute(Command) line: 156
> DawnCompositeEditPartFactory$8(GraphicalEditPart).performRequest(Request) line: 1125
> SelectEditPartTracker.performOpen() line: 194
> SelectEditPartTracker.handleDoubleClick(int) line: 137
> SelectEditPartTracker(AbstractTool).mouseDoubleClick(MouseEvent, EditPartViewer) line: 1069
> DelegatingDragEditPartsTracker(SelectionTool).mouseDoubleClick(MouseEvent, EditPartViewer) line: 527
> SelectionToolEx(SelectionTool).mouseDoubleClick(MouseEvent, EditPartViewer) line: 527
> DiagramEditDomain(EditDomain).mouseDoubleClick(MouseEvent, EditPartViewer) line: 231
> DomainEventDispatcher.dispatchMouseDoubleClicked(MouseEvent) line: 291
> LightweightSystem$EventHandler.mouseDoubleClick(MouseEvent) line: 518
> TypedListener.handleEvent(Event) line: 195
> EventTable.sendEvent(Event) line: 84
> FigureCanvas(Widget).sendEvent(Event) line: 1053
> Display.runDeferredEvents() line: 4165
> Display.readAndDispatch() line: 3754
> Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2701
> Workbench.runUI() line: 2665
> Workbench.access$4(Workbench) line: 2499
> Workbench$7.run() line: 679
> Realm.runWithDefault(Realm, Runnable) line: 332
> Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 668
> PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149
> IDEApplication.start(IApplicationContext) line: 123
> EclipseAppHandle.run(Object) line: 196
> EclipseAppLauncher.runApplication(Object) line: 110
> EclipseAppLauncher.start(Object) line: 79
> EclipseStarter.run(Object) line: 344
> EclipseStarter.run(String[], Runnable) line: 179
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not available
> Method.invoke(Object, Object...) line: not available
> Main.invokeFramework(String[], URL[]) line: 622
> Main.basicRun(String[]) line: 577
> Main.run(String[]) line: 1410
> Main.main(String[]) line: 1386
>
>
>
> Thread [InvalidationRunner-Transaction 5 [MAIN]] (Suspended)
> owns: TransactionImpl (id=444)
> owns: CDOTransactionImpl (id=367)
> waited by: Thread [main] (Running)
> waiting for: Object (id=445)
> Object.wait(long) line: not available [native method]
> Object.wait() line: 485 [local variables unavailable]
> ThreadJob.waitForRun(ThreadJob, IProgressMonitor, InternalJob, Thread) line: 272
> ThreadJob.joinRun(ThreadJob, IProgressMonitor) line: 199
> ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 92
> JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 286
> Lock.uiSafeAcquire(boolean) line: 359
> DawnDiagramEditingDomainFactory$DawnDiagramEditingDomain(TransactionalEditingDomainImpl).acquire(InternalTransaction)
> line: 580
I *think* this call leads to an attempt to lock the UI from the background thread. But I can't find it in the current
4.1 code base. I strongly recommend to switch to 4.1 and retry it ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> DawnDiagramEditingDomainFactory$DawnDiagramEditingDomain(TransactionalEditingDomainImpl).activate(InternalTransaction)
> line: 508
> TransactionImpl.start() line: 204
> DawnDiagramEditingDomainFactory$DawnDiagramEditingDomain(TransactionalEditingDomainImpl).startTransaction(boolean,
> Map<?,?>) line: 424
> DawnDiagramEditingDomainFactory$DawnDiagramEditingDomain(TransactionalEditingDomainImpl).runExclusive(Runnable)
> line: 321
> DawnDiagramUpdater.refreshEditPart(EditPart, DiagramDocumentEditor) line: 79
> DawnGMFHandler.handleObject(CDOObject) line: 243
> DawnGMFHandler.handleViewInvalidationEvent(CDOViewInvalidationEvent) line: 78
> DawnGMFHandler(BasicDawnListener).notifyEvent(IEvent) line: 61
> Notifier.fireEventSafe(IEvent, IListener[]) line: 136
> CDOTransactionImpl(Notifier).fireEvent(IEvent, IListener[]) line: 100
> CDOTransactionImpl(CDOViewImpl).fireInvalidationEvent(long, Map<CDOObject,CDORevisionDelta>, Set<CDOObject>) line:
> 604
> CDOTransactionImpl(CDOViewImpl).doInvalidate(CDOBranch, long, List<CDORevisionKey>, List<CDOIDAndVersion>,
> Map<CDOID,InternalCDORevision>) line: 508
> CDOViewImpl$InvalidationRunnable.run() line: 1241
> CDOViewImpl$2(QueueRunner).work(Worker$WorkContext, Runnable) line: 26
> CDOViewImpl$2(QueueRunner).work(Worker$WorkContext, Object) line: 1
> CDOViewImpl$2(QueueWorker<E>).doWork(Worker$WorkContext) line: 81
> CDOViewImpl$2(QueueWorker<E>).work(Worker$WorkContext) line: 72
> Worker$WorkerThread.run() line: 206
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #886185 is a reply to message #886025] |
Thu, 14 June 2012 11:59 |
Tim Schaefer Messages: 49 Registered: June 2011 Location: Marburg, Germany |
Member |
|
|
Hi Eike,
using 4.1 makes no difference, however I finally found a way to make it work!
Instead of letting the Dawn-generated wizard open a new transaction (for the resource creation), I give the wizard the CDOView of the semantic element from the command (element.cdoView()). I believe, in this execution-context, it is safe to assume that this view is always a transaction (i.e. not a read-only view).
Creating the new resource with this transaction, there is no need for the InvalidationRunner to make its work.
Do you see any problems with this, or is it ok to do it this way?
Regards,
Tim
|
|
|
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #887381 is a reply to message #886185] |
Sat, 16 June 2012 14:10 |
Martin Fluegge Messages: 141 Registered: July 2009 |
Senior Member |
|
|
Hi Tim,
sorry, I can't follow. Where did you do your changes? In the generated
Wizard? Actually the wizard itself does not create a transaction. Could
you point me to a code line or provide a snippet.
Cheers,
Martin
Am 14.06.2012 13:59, schrieb Tim Schaefer:
> Hi Eike,
>
> using 4.1 makes no difference, however I finally found a way to make it
> work! :)
> Instead of letting the Dawn-generated wizard open a new transaction (for
> the resource creation), I give the wizard the CDOView of the semantic
> element from the command (element.cdoView()). I believe, in this
> execution-context, it is safe to assume that this view is always a
> transaction (i.e. not a read-only view).
> Creating the new resource with this transaction, there is no need for
> the InvalidationRunner to make its work.
>
> Do you see any problems with this, or is it ok to do it this way?
>
> Regards,
> Tim
|
|
| | |
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #887940 is a reply to message #887428] |
Sun, 17 June 2012 11:47 |
Martin Fluegge Messages: 141 Registered: July 2009 |
Senior Member |
|
|
Hi Tim,
comments inline...
Am 16.06.2012 17:54, schrieb Tim Schaefer:
> Hi Martin,
>
> in the WorkspaceModifyOperation executed by the Dawn-generated
> performFinish() method a new transaction is opened:
>
> ResourceSet resourceSet = new ResourceSetImpl();
> URI resourceURI = newResourceCreationPage.getURI();
> CDOTransaction transaction =
> CDOConnectionUtil.instance.openCurrentTransaction(resourceSet,
> resourceURI.toString());
> Resource resource = transaction.getOrCreateResource(resourceURI.path());
> ..
>
I am still a bit confused. This code look rather old. Did you generate
teh GMF dawn extension with Dawn 1.0 or a previous version? Could you
try regenrating with Dawn 2.0?
> I changed this to
>
> CDOTransaction transaction = (CDOTransaction) view;
Is "view" the view from the semantic resource?
> Resource resource = transaction.getOrCreateResource(resourceURI.path());
> ..
>
> I added the view as argument to the wizard constructor and assign it to
> the view member.
> I removed these lines:
>
> CDOConnectionUtil.instance.init(
> PreferenceConstants.getRepositoryName(),
> PreferenceConstants.getProtocol(),
> PreferenceConstants.getServerName());
> CDOSession session = CDOConnectionUtil.instance.openSession();
> view = CDOConnectionUtil.instance.openView(session);
>
> This wizard is only used by my command (i.e. not from the workbench).
> My command has a reference to the semantic element (which is managed by
> gmf's editing domain) and passes the view it gets by calling cdoView()
> on this element.
>
> I'm pretty sure that this view is always a transaction, since I don't
> see a reason why the elements managed by gmf should be loaded into a
> read-only view later, but maybe there is something I'm not aware of.
If it really comes from the semantic resource it could only be a view.
If the users wants to prevent changes in the semantic resource but allow
to change and persit the changes in the diagram. In this case it could
make sense to open the sematic resource in a CDOView and the notational
one in a transaction.
Cheers,
Martin
>
> Regards,
> Tim
|
|
| | |
Goto Forum:
Current Time: Wed Sep 25 00:11:25 GMT 2024
Powered by FUDForum. Page generated in 0.06998 seconds
|