Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Stateful vs Singleton
Stateful vs Singleton [message #426078] Mon, 15 December 2008 18:56 Go to next message
Conor O'Mahony is currently offline Conor O'MahonyFriend
Messages: 108
Registered: July 2009
Senior Member
Hi,

I was looking for a way to filter the properties of my emf objects in the properties view, depending
on certain conditions of the object being shown. By editing the getPropertyDescriptors() method in
the xxxItemProvider class I was able to select which properties descriptors I wanted to add, but
this method was only being called once per type. I figured by changing the Provider Type to Stateful
instead of Singleton it would solve this problem and it did. The EMF book says that this "doubles
the number of objects in the application" therefore presumably impacting performance, so my
questions are -
1. Should I avoid doing this and if so is there an alternative solution?
2. If I stick to this solution are there any other repercussions I should be aware of, will it
change how my application currently works in any way?

I am using
Eclipse 3.3 (planning to move to 3.4)
EMF 2.3

Many thanks for your help,
Conor
Re: Stateful vs Singleton [message #426081 is a reply to message #426078] Mon, 15 December 2008 19:41 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33139
Registered: July 2009
Senior Member
Conor,

Comments below.

Conor O'Mahony wrote:
> Hi,
>
> I was looking for a way to filter the properties of my emf objects in
> the properties view, depending on certain conditions of the object
> being shown. By editing the getPropertyDescriptors() method in the
> xxxItemProvider class I was able to select which properties
> descriptors I wanted to add, but this method was only being called
> once per type.
Instead of caching it, you could recompute it each time it's called.
> I figured by changing the Provider Type to Stateful instead of
> Singleton it would solve this problem and it did. The EMF book says
> that this "doubles the number of objects in the application" therefore
> presumably impacting performance, so my questions are -
> 1. Should I avoid doing this and if so is there an alternative solution?
Yes, just don't cache the descriptors. Or flush the cache every thing
the argument object is different from the last time.
> 2. If I stick to this solution are there any other repercussions I
> should be aware of, will it change how my application currently works
> in any way?
Not really no. Just more adapters...
>
> I am using
> Eclipse 3.3 (planning to move to 3.4)
> EMF 2.3
>
> Many thanks for your help,
> Conor


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Stateful vs Singleton [message #426098 is a reply to message #426081] Tue, 16 December 2008 10:37 Go to previous messageGo to next message
Conor O'Mahony is currently offline Conor O'MahonyFriend
Messages: 108
Registered: July 2009
Senior Member
Hi Ed,

Thanks for your help. How do I flush the cache? I tried changing the getPropertyDescriptors() method
in my XXXItemProvider class to clear the itemProvider list but this method is still only called once
when the Item Provider pattern is Singleton.

Many thanks,
Conor

Ed Merks wrote:
> Conor,
>
> Comments below.
>
> Conor O'Mahony wrote:
>> Hi,
>>
>> I was looking for a way to filter the properties of my emf objects in
>> the properties view, depending on certain conditions of the object
>> being shown. By editing the getPropertyDescriptors() method in the
>> xxxItemProvider class I was able to select which properties
>> descriptors I wanted to add, but this method was only being called
>> once per type.
> Instead of caching it, you could recompute it each time it's called.
>> I figured by changing the Provider Type to Stateful instead of
>> Singleton it would solve this problem and it did. The EMF book says
>> that this "doubles the number of objects in the application" therefore
>> presumably impacting performance, so my questions are -
>> 1. Should I avoid doing this and if so is there an alternative solution?
> Yes, just don't cache the descriptors. Or flush the cache every thing
> the argument object is different from the last time.
>> 2. If I stick to this solution are there any other repercussions I
>> should be aware of, will it change how my application currently works
>> in any way?
> Not really no. Just more adapters...
>>
>> I am using
>> Eclipse 3.3 (planning to move to 3.4)
>> EMF 2.3
>>
>> Many thanks for your help,
>> Conor
Re: Stateful vs Singleton [message #426100 is a reply to message #426098] Tue, 16 December 2008 10:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33139
Registered: July 2009
Senior Member
Conor,

They're cached

Conor O'Mahony wrote:
> Hi Ed,
>
> Thanks for your help. How do I flush the cache? I tried changing the
> getPropertyDescriptors() method in my XXXItemProvider class to clear
> the itemProvider list but this method is still only called once when
> the Item Provider pattern is Singleton.
It's called each time the descriptors are needed, but the value is
cached in itemPropertyDescriptors and the code is guarded to test for
null. So setting itemPropertyDescriptors to null before calling super
will force it to be recomputed.
>
> Many thanks,
> Conor
>
> Ed Merks wrote:
>> Conor,
>>
>> Comments below.
>>
>> Conor O'Mahony wrote:
>>> Hi,
>>>
>>> I was looking for a way to filter the properties of my emf objects
>>> in the properties view, depending on certain conditions of the
>>> object being shown. By editing the getPropertyDescriptors() method
>>> in the xxxItemProvider class I was able to select which properties
>>> descriptors I wanted to add, but this method was only being called
>>> once per type.
>> Instead of caching it, you could recompute it each time it's called.
>>> I figured by changing the Provider Type to Stateful instead of
>>> Singleton it would solve this problem and it did. The EMF book says
>>> that this "doubles the number of objects in the application"
>>> therefore presumably impacting performance, so my questions are -
>>> 1. Should I avoid doing this and if so is there an alternative
>>> solution?
>> Yes, just don't cache the descriptors. Or flush the cache every
>> thing the argument object is different from the last time.
>>> 2. If I stick to this solution are there any other repercussions I
>>> should be aware of, will it change how my application currently
>>> works in any way?
>> Not really no. Just more adapters...
>>>
>>> I am using
>>> Eclipse 3.3 (planning to move to 3.4)
>>> EMF 2.3
>>>
>>> Many thanks for your help,
>>> Conor


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Stateful vs Singleton [message #426102 is a reply to message #426100] Tue, 16 December 2008 11:38 Go to previous messageGo to next message
Conor O'Mahony is currently offline Conor O'MahonyFriend
Messages: 108
Registered: July 2009
Senior Member
Hi Ed,

I modified the getPropertyDescriptors() method as you suggested -

public List getPropertyDescriptors(Object object)
{
itemPropertyDescriptors = null;
System.out.println("TypeXXXItemProvider.getPropertyDescriptors ");
// if (itemPropertyDescriptors == null)
// {
super.getPropertyDescriptors(object);
TypeXXX component = (TypeXXX) object;
if (component.isWhatever())
{
addXXXPropertyDescriptor();
}

And ran the application, this worked and updated the properties view as expected.
However then I noticed that my System.out.println() was printed multiple times whenever I selected
an object, the method is called multiple times on one selection - is this normal?

Many thanks,
Conor


Ed Merks wrote:
> Conor,
>
> They're cached
>
> Conor O'Mahony wrote:
>> Hi Ed,
>>
>> Thanks for your help. How do I flush the cache? I tried changing the
>> getPropertyDescriptors() method in my XXXItemProvider class to clear
>> the itemProvider list but this method is still only called once when
>> the Item Provider pattern is Singleton.
> It's called each time the descriptors are needed, but the value is
> cached in itemPropertyDescriptors and the code is guarded to test for
> null. So setting itemPropertyDescriptors to null before calling super
> will force it to be recomputed.
>>
>> Many thanks,
>> Conor
>>
>> Ed Merks wrote:
>>> Conor,
>>>
>>> Comments below.
>>>
>>> Conor O'Mahony wrote:
>>>> Hi,
>>>>
>>>> I was looking for a way to filter the properties of my emf objects
>>>> in the properties view, depending on certain conditions of the
>>>> object being shown. By editing the getPropertyDescriptors() method
>>>> in the xxxItemProvider class I was able to select which properties
>>>> descriptors I wanted to add, but this method was only being called
>>>> once per type.
>>> Instead of caching it, you could recompute it each time it's called.
>>>> I figured by changing the Provider Type to Stateful instead of
>>>> Singleton it would solve this problem and it did. The EMF book says
>>>> that this "doubles the number of objects in the application"
>>>> therefore presumably impacting performance, so my questions are -
>>>> 1. Should I avoid doing this and if so is there an alternative
>>>> solution?
>>> Yes, just don't cache the descriptors. Or flush the cache every
>>> thing the argument object is different from the last time.
>>>> 2. If I stick to this solution are there any other repercussions I
>>>> should be aware of, will it change how my application currently
>>>> works in any way?
>>> Not really no. Just more adapters...
>>>>
>>>> I am using
>>>> Eclipse 3.3 (planning to move to 3.4)
>>>> EMF 2.3
>>>>
>>>> Many thanks for your help,
>>>> Conor
Re: Stateful vs Singleton [message #426103 is a reply to message #426102] Tue, 16 December 2008 12:16 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33139
Registered: July 2009
Senior Member
Conor,

Yes, this method is called a lot by the underlying providers in the
properties view. The performance impact is typically not noticeable,
but if it is, you might cache the most recently "object" and null out
the list only when that changes (assuming the property descriptors don't
change depending on some feature's value for that object).


Conor O'Mahony wrote:
> Hi Ed,
>
> I modified the getPropertyDescriptors() method as you suggested -
>
> public List getPropertyDescriptors(Object object)
> {
> itemPropertyDescriptors = null;
> System.out.println("TypeXXXItemProvider.getPropertyDescriptors ");
> // if (itemPropertyDescriptors == null)
> // {
> super.getPropertyDescriptors(object);
> TypeXXX component = (TypeXXX) object;
> if (component.isWhatever())
> {
> addXXXPropertyDescriptor();
> }
>
> And ran the application, this worked and updated the properties view
> as expected.
> However then I noticed that my System.out.println() was printed
> multiple times whenever I selected an object, the method is called
> multiple times on one selection - is this normal?
>
> Many thanks,
> Conor
>
>
> Ed Merks wrote:
>> Conor,
>>
>> They're cached
>>
>> Conor O'Mahony wrote:
>>> Hi Ed,
>>>
>>> Thanks for your help. How do I flush the cache? I tried changing the
>>> getPropertyDescriptors() method in my XXXItemProvider class to clear
>>> the itemProvider list but this method is still only called once when
>>> the Item Provider pattern is Singleton.
>> It's called each time the descriptors are needed, but the value is
>> cached in itemPropertyDescriptors and the code is guarded to test for
>> null. So setting itemPropertyDescriptors to null before calling
>> super will force it to be recomputed.
>>>
>>> Many thanks,
>>> Conor
>>>
>>> Ed Merks wrote:
>>>> Conor,
>>>>
>>>> Comments below.
>>>>
>>>> Conor O'Mahony wrote:
>>>>> Hi,
>>>>>
>>>>> I was looking for a way to filter the properties of my emf objects
>>>>> in the properties view, depending on certain conditions of the
>>>>> object being shown. By editing the getPropertyDescriptors() method
>>>>> in the xxxItemProvider class I was able to select which properties
>>>>> descriptors I wanted to add, but this method was only being called
>>>>> once per type.
>>>> Instead of caching it, you could recompute it each time it's called.
>>>>> I figured by changing the Provider Type to Stateful instead of
>>>>> Singleton it would solve this problem and it did. The EMF book
>>>>> says that this "doubles the number of objects in the application"
>>>>> therefore presumably impacting performance, so my questions are -
>>>>> 1. Should I avoid doing this and if so is there an alternative
>>>>> solution?
>>>> Yes, just don't cache the descriptors. Or flush the cache every
>>>> thing the argument object is different from the last time.
>>>>> 2. If I stick to this solution are there any other repercussions I
>>>>> should be aware of, will it change how my application currently
>>>>> works in any way?
>>>> Not really no. Just more adapters...
>>>>>
>>>>> I am using
>>>>> Eclipse 3.3 (planning to move to 3.4)
>>>>> EMF 2.3
>>>>>
>>>>> Many thanks for your help,
>>>>> Conor


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:disable code generation for certain parts of XML Schema?
Next Topic:[CDO] CDORevisionImpl.eIsSet() works incorrectly
Goto Forum:
  


Current Time: Tue Apr 23 07:05:13 GMT 2024

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

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

Back to the top