Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Component Services / July 2005

Tip: Looking for answers? Try searching our database.

COM+ object not being release back to the pool

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
VinDotNet - 30 Jun 2005 14:09 GMT
Here's the Scenario I am facing:
I've got a winform managed c++ client which connects to my managed
COM+ server application (by making createinstance, then typecasting
the object to an interface, then calling methods over it). This COM+
server application is from a C# dll that has references to Interop dlls
(com type libraries written in unmanaged c++) and MC++ wrappers over
unmanaged c++ code. I've got object pooling enabled with (Min : 0 and
Max : 1048576). I've got a db connection in the construct() method of
the servicedcomponent.

I am on
1. VS.Net 2003
2. .Net framework 1.1
3. COM+ is a server application with JIT disabled, object pooling
enabled.

Issue:
When I run the winform client for the first time, everything goes well.
But when I close it the object stays there and isn't released back to
the pool. I mean in the component services mmc, event statistics i can
see Objects: 1 Activated: 1 Pooled: 1.

If I invoke my COM+ component from a vbscript, C# client, unmanaged c++
client (by cocreateinstance()) the objects are being returned back to
the pool properly. Point to note here is I don't even call the
ServicedComponent.DisposeObject() at client.
Whereas it doesn't work in my above scenario (winform managed c++)
client even after I do a disposeobject or Marshal.ReleaseComObject().

No matter what, the objects keep on growing as many no of clients
getting connected.

1. How to make them released back to the pool immediately as the client
is closed? or what am I doing wrong here?

Could you please help me out to resolve this issue. I've searched over
the web everywhere, read many of answers to these kind of
questions in newsgroups, tried various options, but I am yet to find a
solution.
Here's a list of options I tried and couldn't succeed.
    1. ServicedComponent.DisposeObject(obj); at the client.
    2. Called Marshal.ReleaseComObject(interop object) at the client.
Released all com objects.
    3. ServicedComponent.DisposeObject(this); at the server, just after
deactivate() and disconnect().
    4. Called Marshal.ReleaseComObject(interop object) at the server.
Released all com objects.
    5. Deactivate() was not getting called when winform client closes. So
I tried forcibly calling it from server's disconnect method. Didn't
work.
    6. Set JIT activation to true in component's properties.
    7. Set Object pooling disabled in component's properties.

2. Also one more question, if my object pooling is enabled, and the
construct() method of servicedcomponent is called everytime a request
comes, does it mean object pooling is of no use here? In object
pooling, if a second request comes, isn't it not supposed to invoke
construct() and directly call activate()?

Thanks and Regards,
Vin
aethyr_@hotmail.com - 26 Jul 2005 23:55 GMT
> Here's the Scenario I am facing:
> I've got a winform managed c++ client which connects to my managed
[quoted text clipped - 5 lines]
> Max : 1048576). I've got a db connection in the construct() method of
> the servicedcomponent...

How are you creating the COM+ application from your managed c++ client?

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.