Re: CoInitialize failure with many processes
- From: "Brian Muth" <bmuth@xxxxxxxx>
- Date: Thu, 2 Apr 2009 14:40:51 -0700
"Dan" <Dan@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:BE92EC61-A5B2-4D2F-845F-BCEC7BE6D8B3@xxxxxxxxxxxxxxxx
Brian,
As I continue to dig through this code, it appears that it is using COM to
directly communicate with the SQL server. I'm learning as I go here.
Prior to calling CoInitialize(NULL), there is nothing done of interest.
(e.g. Setting thread priority, parsing command line arguments, etc) After
the CoInitialize, the connection is made using a msado15.tlh file and a
_connection object (apparently an ADO object, or ActiveX Data Object).
CreateInstance is called on a _ConnectionPtr object, then Open is called on
this object with the following connection string:
"Provider=sqloledb;Server=%*.*S%S%*.*S;Database=%*.*S%SSystem;Trusted_Connection=Yes;"
The resulting object is returned as a _variant_t object casted from an
(IUnknown*) pointer. This variant object is passed into a _RecordsetPtr
object's Open function along with an SQL statement casted as a _variant_t
object as well.
Regarding the Performance Monitor, I haven't seen anything out of the
ordinary. What performance objects and counters should I be looking at?
This was a very helpful post. I wish in fact that you provided this very relevant information at the beginning.
I'm surmising that you have a simple application that is accessing SQL Server using classic ADO. This is a simple client-server type of relationship. Scaling is definitely going to be an issue here, since SQL Server can only handle so many connections at one time. Double-check the code to ensure that any ADO connection is closed explicitly. This is especially important if you are opening and closing connections more than once, as leaving out the call to Close() will accelerate exhaustion of SQL resources.
You can use the SQL Server Profiler to examine the number of connections while you start launching. This is an extremely important tool for you, so if you are unfamiliar with it, now is the time to do your research and learn how to use it properly. Also, use your favourite search engine and enter "ADO SQL Connection Pooling" and you will find lots of hits relevant to this problem.
You will need to fully leverage SQL Server connection pooling. There are probably several ways of tackling it but I would recommend that a very simple COM DLL be written that calls the SQL Server on behalf of any client process. Then install this COM DLL into Component Services to change it to a COM+ application. This will enable connection pooling, and you should be able to easily launch hundreds of processes without running into the problem you are currently facing. Your application is no longer a client-server architecture, but now an n-tier architecture, and will scale much, much better.
This simple COM+ DLL could be written in VB6, although C++ of course could also be used.
Good luck with your project.
Regards,
Brian
.
- Follow-Ups:
- References:
- CoInitialize failure with many processes
- From: Dan
- RE: CoInitialize failure with many processes
- From: Dan
- Re: CoInitialize failure with many processes
- From: Brian Muth
- Re: CoInitialize failure with many processes
- From: Brian Muth
- Re: CoInitialize failure with many processes
- From: Dan
- CoInitialize failure with many processes
- Prev by Date: Re: CoInitialize failure with many processes
- Next by Date: Re: CoInitialize failure with many processes
- Previous by thread: Re: CoInitialize failure with many processes
- Next by thread: Re: CoInitialize failure with many processes
- Index(es):
Relevant Pages
|
