Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO/Dawn] Deadlock on accessing CDOView
[CDO/Dawn] Deadlock on accessing CDOView [message #883515] Fri, 08 June 2012 17:40 Go to next message
Tim Schaefer is currently offline Tim SchaeferFriend
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 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6460
Registered: July 2009
Senior Member
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


Re: [CDO/Dawn] Deadlock on accessing CDOView [message #883762 is a reply to message #883707] Sat, 09 June 2012 10:04 Go to previous messageGo to next message
Tim Schaefer is currently offline Tim SchaeferFriend
Messages: 49
Registered: June 2011
Location: Marburg, Germany
Member
Hi Eike,

thanks for your reply.
I'm not so experienced in multi-threading, sorry Sad
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 #885000 is a reply to message #883762] Tue, 12 June 2012 08:44 Go to previous messageGo to next message
Tim Schaefer is currently offline Tim SchaeferFriend
Messages: 49
Registered: June 2011
Location: Marburg, Germany
Member
Dear Eike,

can you give me some general information about the InvalidationRunner threads?
Is there maybe a way to wait for a InvalidationRunner of a given view until it has done its work, something I could do before my command is executed?
Though it's a background thread that probably has something to do all the time...

I tried (write-)locking the cdoobject before command execution but that didn't help.

Regards,
Tim
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #885015 is a reply to message #885000] Tue, 12 June 2012 09:12 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6460
Registered: July 2009
Senior Member
Am 12.06.2012 10:44, schrieb Tim Schaefer:
> Dear Eike,
>
> can you give me some general information about the InvalidationRunner threads?
Today is our GA build day. I may have time to answer in more detail tomorrow...

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: [CDO/Dawn] Deadlock on accessing CDOView [message #885177 is a reply to message #883707] Tue, 12 June 2012 15:04 Go to previous messageGo to next message
Martin Fluegge is currently offline Martin FlueggeFriend
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 #885231 is a reply to message #885177] Tue, 12 June 2012 16:35 Go to previous messageGo to next message
Tim Schaefer is currently offline Tim SchaeferFriend
Messages: 49
Registered: June 2011
Location: Marburg, Germany
Member
Hi Martin,

I closed both the CDOSessions and the Dawn Explorer View, then invoked the command but without success.
Still deadlocked with the InvalidationRunner thread. Sad

Regards,
Tim
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #886023 is a reply to message #885000] Thu, 14 June 2012 04:18 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6460
Registered: July 2009
Senior Member
Am 12.06.2012 10:44, schrieb Tim Schaefer:
> Dear Eike,
>
> can you give me some general information about the InvalidationRunner threads?
> Is there maybe a way to wait for a InvalidationRunner of a given view until it has done its work, something I could do
> before my command is executed?
> Though it's a background thread that probably has something to do all the time...
>
> I tried (write-)locking the cdoobject before command execution but that didn't help.
Write locks protect the central model against other remote changes. If you want to protect your local model against
background updates you can synchronize your code on the CDOView/CDOTransaction instance.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: [CDO/Dawn] Deadlock on accessing CDOView [message #886025 is a reply to message #883762] Thu, 14 June 2012 04:26 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6460
Registered: July 2009
Senior Member
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
>
>


Re: [CDO/Dawn] Deadlock on accessing CDOView [message #886185 is a reply to message #886025] Thu, 14 June 2012 11:59 Go to previous messageGo to next message
Tim Schaefer is currently offline Tim SchaeferFriend
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! Smile
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 Go to previous messageGo to next message
Martin Fluegge is currently offline Martin FlueggeFriend
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 #887428 is a reply to message #887381] Sat, 16 June 2012 15:54 Go to previous messageGo to next message
Tim Schaefer is currently offline Tim SchaeferFriend
Messages: 49
Registered: June 2011
Location: Marburg, Germany
Member
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 changed this to
CDOTransaction transaction = (CDOTransaction) view;
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.

Regards,
Tim
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #887435 is a reply to message #887428] Sat, 16 June 2012 16:11 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6460
Registered: July 2009
Senior Member
Am 16.06.2012 17:54, schrieb Tim Schaefer:
> [...]
> 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.
I don't know how Dawn works but generally it can make sense to use a CDOView if you want to share the model instances
across multiple Eclipse ViewParts or so. It's best to always check that in framework code.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: [CDO/Dawn] Deadlock on accessing CDOView [message #887940 is a reply to message #887428] Sun, 17 June 2012 11:47 Go to previous messageGo to next message
Martin Fluegge is currently offline Martin FlueggeFriend
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
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #887941 is a reply to message #887435] Sun, 17 June 2012 11:49 Go to previous messageGo to next message
Martin Fluegge is currently offline Martin FlueggeFriend
Messages: 141
Registered: July 2009
Senior Member
Am 16.06.2012 18:11, schrieb Eike Stepper:
> Am 16.06.2012 17:54, schrieb Tim Schaefer:
>> [...]
>> 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.
> I don't know how Dawn works but generally it can make sense to use a
> CDOView if you want to share the model instances across multiple Eclipse
> ViewParts or so. It's best to always check that in framework code.

Yep. Or in cases where you want to provide a read-only editor where uses
can only view the changes of others.

>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
Re: [CDO/Dawn] Deadlock on accessing CDOView [message #888713 is a reply to message #887941] Mon, 18 June 2012 14:24 Go to previous message
Tim Schaefer is currently offline Tim SchaeferFriend
Messages: 49
Registered: June 2011
Location: Marburg, Germany
Member
Hi Martin,

the code generated with Dawn 2.0 looks exactly like generated with 1.0.
I think you misunderstood one thing:
The wizard is a dawn-*emf* generated one, opened from within a command in a dawn-gmf generated diagram editor.
It's absolutely ok for default use-cases that a dawn-emf generated wizard opens a new transaction, only in my case it is required to use the semantic element as a relative.
Its view was always a transaction whenever I tested and I think I can leave it like that.

Thanks both of you for your help. Smile

Regards,
Tim
Previous Topic:[CDO/Teneo/Hibernate] java.lang.IllegalArgumentException: Invalid type: java.math.BigDecimal
Next Topic:ContentHandler.UNSPECIFIED_CONTENT_TYPE vs null
Goto Forum:
  


Current Time: Sat Dec 14 21:08:43 GMT 2019

Powered by FUDForum. Page generated in 0.03003 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top