Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [EEF] Deadlocks when using with transactional editing domains
[EEF] Deadlocks when using with transactional editing domains [message #819993] Tue, 13 March 2012 15:37 Go to next message
Jan Mauersberger is currently offline Jan Mauersberger
Messages: 119
Registered: July 2009
Senior Member
Hi,

we are using EEF 1.0.2 for Indigo with resource sets that have
transactional editing domains. There is code in the base class
SinglePartPropertiesEditingComponent#initializeSemanticAdapter (or more
precisely in PropertiesEditingSemanticLister#notifyChanged that is doing
a thread switch to the UI thread regardless of the kind of notification.
However, in some cases we are facing deadlocks, e.g. in case the adapter
is removed, due to several other side constraints.

Is it possible to make this code more smart or flexible or at least
easier for custom base classes to intercept such synchronized calls to
the UI thread?

Thanks in advance
Jan
Re: [EEF] Deadlocks when using with transactional editing domains [message #821583 is a reply to message #819993] Thu, 15 March 2012 14:59 Go to previous messageGo to next message
Stephane Bouchet is currently offline Stephane Bouchet
Messages: 260
Registered: July 2009
Senior Member
Hi Jan,

The notifyChanged Method can be extended by the generated classes in
order to meet your needs.

We use EEF in transactional editing domains, too, and did not notify
somes glitches.

Can you provide a test case in Bugzilla ?

thanks,


Le 13/03/2012 16:37, Jan Mauersberger a écrit :
> Hi,
>
> we are using EEF 1.0.2 for Indigo with resource sets that have
> transactional editing domains. There is code in the base class
> SinglePartPropertiesEditingComponent#initializeSemanticAdapter (or more
> precisely in PropertiesEditingSemanticLister#notifyChanged that is doing
> a thread switch to the UI thread regardless of the kind of notification.
> However, in some cases we are facing deadlocks, e.g. in case the adapter
> is removed, due to several other side constraints.
>
> Is it possible to make this code more smart or flexible or at least
> easier for custom base classes to intercept such synchronized calls to
> the UI thread?
>
> Thanks in advance
> Jan


--
Cheers,

Stéphane Bouchet, OBEO
Re: [EEF] Deadlocks when using with transactional editing domains [message #822391 is a reply to message #821583] Fri, 16 March 2012 14:54 Go to previous messageGo to next message
Jan Mauersberger is currently offline Jan Mauersberger
Messages: 119
Registered: July 2009
Senior Member
Hi Stephane,

thanks for your reply. Could you please give me some hint how to
customize the code best? The problematic code is located in
PropertiesEditingSemanticLister#notifyChanged as you probably was
referring to. However, the instance of this class is created as
anonymous sub-class in
StandardPropertiesEditionComponent#initializeSemanticAdapter as

protected PropertiesEditingSemanticLister initializeSemanticAdapter() {
return new PropertiesEditingSemanticLister(this) {

public void runUpdateRunnable(Notification msg) {
updatePart(msg);
}
};
}


That forces us currently to derive from
SinglePartPropertiesEditingComponent and overwrite
initializeSemanticAdapter. Any other (better) way to do it?

I do not have a reproducible scenario at least not to easily write a
test case. I also do not say that this is a bug of EEF or similar.
However, at this point in time, the UI thread is blocked and locked
already, executing a sync operation is not possible in our scenario so I
need some flexibility and customization here.

Cheers Jan

> Hi Jan,
>
> The notifyChanged Method can be extended by the generated classes in
> order to meet your needs.
>
> We use EEF in transactional editing domains, too, and did not notify
> somes glitches.
>
> Can you provide a test case in Bugzilla ?
>
> thanks,
>
>
> Le 13/03/2012 16:37, Jan Mauersberger a écrit :
>> Hi,
>>
>> we are using EEF 1.0.2 for Indigo with resource sets that have
>> transactional editing domains. There is code in the base class
>> SinglePartPropertiesEditingComponent#initializeSemanticAdapter (or more
>> precisely in PropertiesEditingSemanticLister#notifyChanged that is doing
>> a thread switch to the UI thread regardless of the kind of notification.
>> However, in some cases we are facing deadlocks, e.g. in case the adapter
>> is removed, due to several other side constraints.
>>
>> Is it possible to make this code more smart or flexible or at least
>> easier for custom base classes to intercept such synchronized calls to
>> the UI thread?
>>
>> Thanks in advance
>> Jan
>
>
Re: [EEF] Deadlocks when using with transactional editing domains [message #830380 is a reply to message #822391] Tue, 27 March 2012 14:53 Go to previous message
Stephane Bouchet is currently offline Stephane Bouchet
Messages: 260
Registered: July 2009
Senior Member
hi jan,


Le 16/03/2012 15:54, Jan Mauersberger a écrit :
> Hi Stephane,
>
> thanks for your reply. Could you please give me some hint how to
> customize the code best? The problematic code is located in
> PropertiesEditingSemanticLister#notifyChanged as you probably was
> referring to. However, the instance of this class is created as
> anonymous sub-class in
> StandardPropertiesEditionComponent#initializeSemanticAdapter as
>
> protected PropertiesEditingSemanticLister initializeSemanticAdapter() {
> return new PropertiesEditingSemanticLister(this) {
>
> public void runUpdateRunnable(Notification msg) {
> updatePart(msg);
> }
> };
> }
>
>
> That forces us currently to derive from
> SinglePartPropertiesEditingComponent and overwrite
> initializeSemanticAdapter. Any other (better) way to do it?
>

no, this is what i suggested to you. this is the good way to modify this
specific part of the EEF runtime.

please note that you can use the LeafComponentsSuperClass property on
the eefgen model ( Gen Edition Context object ) to override on each
component of your model.

> I do not have a reproducible scenario at least not to easily write a
> test case. I also do not say that this is a bug of EEF or similar.
> However, at this point in time, the UI thread is blocked and locked
> already, executing a sync operation is not possible in our scenario so I
> need some flexibility and customization here.

i can easily understand your customization needs :) we tried to open the
API to be able to override the Runtime easily, so feel free to open a
request on bugzilla if you want more API customization.

>
> Cheers Jan
>
>> Hi Jan,
>>
>> The notifyChanged Method can be extended by the generated classes in
>> order to meet your needs.
>>
>> We use EEF in transactional editing domains, too, and did not notify
>> somes glitches.
>>
>> Can you provide a test case in Bugzilla ?
>>
>> thanks,
>>
>>
>> Le 13/03/2012 16:37, Jan Mauersberger a écrit :
>>> Hi,
>>>
>>> we are using EEF 1.0.2 for Indigo with resource sets that have
>>> transactional editing domains. There is code in the base class
>>> SinglePartPropertiesEditingComponent#initializeSemanticAdapter (or more
>>> precisely in PropertiesEditingSemanticLister#notifyChanged that is doing
>>> a thread switch to the UI thread regardless of the kind of notification.
>>> However, in some cases we are facing deadlocks, e.g. in case the adapter
>>> is removed, due to several other side constraints.
>>>
>>> Is it possible to make this code more smart or flexible or at least
>>> easier for custom base classes to intercept such synchronized calls to
>>> the UI thread?
>>>
>>> Thanks in advance
>>> Jan
>>
>>
>


--
Cheers,

Stéphane Bouchet, OBEO
Previous Topic:[EEF] EEFTreeMasterPart default adapterFactory with AdapterFactoryEditingDomain
Next Topic:[EEF] Unexpected behavior when properties view is pinned
Goto Forum:
  


Current Time: Sat Oct 25 08:05:06 GMT 2014

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

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