HighTechTalks DotNet Forums  

Should ServicedComponent constructor be "light"?

Dotnet Framework (Component Services) microsoft.public.dotnet.framework.component_services


Discuss Should ServicedComponent constructor be "light"? in the Dotnet Framework (Component Services) forum.



Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old   
Vagif Abilov
 
Posts: n/a

Default Should ServicedComponent constructor be "light"? - 02-08-2005 , 07:53 AM






I just spent a couple of days trying to make .NET component wrapped in a
ServicedComponent class to work. It used to work before and almost in a
sudden started throwing exceptions. After numerous trials and failures I
found out the following:

1. ServicedComponent class used Microsoft Enterprise Instrumentation
Framework assemblies for logging purposes. To simplify the code, I made a
wrapper class for EIF. Depending on how the instance of EIF wrapper was
instantiated, ServicedComponent instance instantiation either succeeded or
failed (with NullReferenceException).

2. General conclusion is that it's better to have static instances of
"heavy" components, otherwise it is instantiated on a call to default
constructor where it may fail.

However I am not very glad to come to such conclustion, because it does not
give me deterministic picture of what's going on. What are the primary
considerations for ServicedComponents dependent assemblies? Can they be
static? Instantiated from a constructor? On a first call? Can its robustness
be affected by making them pooled or JITA?

Thanks in advance

Vagif Abilov

Oslo Norway
vagif @ online.no



Reply With Quote
  #2  
Old   
Eric
 
Posts: n/a

Default Re: Should ServicedComponent constructor be "light"? - 02-10-2005 , 03:12 PM






Anything exposed as COM/COM+ can't be static, but it can call static
methods of other non-COM+ classes.

I don't think it's wise to have much processing in a COM+ constructor.
It can be nasty if an exception occurs in the constructor - will the
class instance still be created? How will the memory be freed? How will
the COM caller handle an exception rasied in the constructor?

I like to keep the COM+ constructors as light as possible. I put the
"heavy" processing in an "Init" method that I define inside the same
class. That way the constuction will succeed, and if there's a problem
in the Init method, the caller will still have an instance to the
object, so there's a well defined state at all times.

Eric


Reply With Quote
  #3  
Old   
Chee Pin Cheam
 
Posts: n/a

Default Re: Should ServicedComponent constructor be "light"? - 03-16-2005 , 07:07 PM



Eric wrote:
Quote:
Anything exposed as COM/COM+ can't be static, but it can call static
methods of other non-COM+ classes.

I don't think it's wise to have much processing in a COM+ constructor.
It can be nasty if an exception occurs in the constructor - will the
class instance still be created? How will the memory be freed? How will
the COM caller handle an exception rasied in the constructor?

I like to keep the COM+ constructors as light as possible. I put the
"heavy" processing in an "Init" method that I define inside the same
class. That way the constuction will succeed, and if there's a problem
in the Init method, the caller will still have an instance to the
object, so there's a well defined state at all times.

Eric

Eric is right. Nothing in COM+ can be static due to context sensitivity.
If you have long initialization for your component, you can consider
using object pooling features of COM+. It is normally helpful for
component that has long initialization time.

Chee Pin



Reply With Quote
Reply




Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.