Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EEF] Deadlocks when using with transactional editing domains
|
| Re: [EEF] Deadlocks when using with transactional editing domains [message #821583 is a reply to message #819993] |
Thu, 15 March 2012 14:59   |
 Stephane Bouchet
Messages: 280
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 |
Jan Mauersberger
Messages: 120
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 |
Stephane Bouchet
Messages: 280
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
|
|
|
Goto Forum:
Current Time: Thu Apr 25 09:21:06 GMT 2024
Powered by FUDForum. Page generated in 0.03592 seconds |
] 
Search
Help
Register
Login
Home
