Chizl
asked on
COM+ Services, ADO, Clustered Invironment.
I'm having problem with COM+ Services failing after three or four days running with an application using ADO in a clustered invironment.
This happens every 3 to 4 days and when we fail it over, it works for 3 to 4 more days.. What happens is ADO can't connect to the SQL server that is on the same machine as the application. I'm using a trusted connection string to connect to SQL using OLEDB. This cluster has around 200GB total storage on an array. Can anyone help me here. Am I doing something wrong in my C++ app connecting to ADO?
Error found in Event Viewer.
========================== ========== ==
The COM+ Services DLL (comsvcs.dll) was unable to load because allocation of thread local storage failed.
Process Name: CDE.exe
Error Code = 0x80070008 : Not enough storage is available to process this command.
COM+ Services Internals Information:
File: .\comsvcs.cpp, Line: 289
========================== ========== ==
I'm #import "location\\ado...etc.." (no_namespace)
I'm not where the code is so I don't know off hand the full location of the ADO DLL, but it's in the code.
I'm using GetRows get get my data..
Using SafeArrays to hold my data as I use it..
I'm kind of throwing these things out there, just in case I don't know something about Clusters and using these different things together causing problems or not.
This happens every 3 to 4 days and when we fail it over, it works for 3 to 4 more days.. What happens is ADO can't connect to the SQL server that is on the same machine as the application. I'm using a trusted connection string to connect to SQL using OLEDB. This cluster has around 200GB total storage on an array. Can anyone help me here. Am I doing something wrong in my C++ app connecting to ADO?
Error found in Event Viewer.
==========================
The COM+ Services DLL (comsvcs.dll) was unable to load because allocation of thread local storage failed.
Process Name: CDE.exe
Error Code = 0x80070008 : Not enough storage is available to process this command.
COM+ Services Internals Information:
File: .\comsvcs.cpp, Line: 289
==========================
I'm #import "location\\ado...etc.." (no_namespace)
I'm not where the code is so I don't know off hand the full location of the ADO DLL, but it's in the code.
I'm using GetRows get get my data..
Using SafeArrays to hold my data as I use it..
I'm kind of throwing these things out there, just in case I don't know something about Clusters and using these different things together causing problems or not.
a problem with releasing resources ?
ASKER
Shouldn't be.. I'm doing a
oRS.Release()
and
oConn.Release()
after every connection. I'm only in the connection for a few milliseconds. One function opens the connection, executes the SQL statement, then uses GetRows, closes recordset, closes connection, then releases both.
The application running this execution is a winsock app. It's still running strong far after COM+ dies and SQL connections are failing.
oRS.Release()
and
oConn.Release()
after every connection. I'm only in the connection for a few milliseconds. One function opens the connection, executes the SQL statement, then uses GetRows, closes recordset, closes connection, then releases both.
The application running this execution is a winsock app. It's still running strong far after COM+ dies and SQL connections are failing.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Yea, I had talked to Microsoft yesterday and that is what they thought it may be. There was a leak and it was because of the location of my CoInit..().
The CoInit was called each time a transaction came in, before using ADO, then CoUninit was called.
I moved CoInit to be called on startup of the application and CoUninit on the closing of the application, and the memory leak went away.
Thanx for the help though.. Guess I will give you the points.. hehe Easy 500 huh?
The CoInit was called each time a transaction came in, before using ADO, then CoUninit was called.
I moved CoInit to be called on startup of the application and CoUninit on the closing of the application, and the memory leak went away.
Thanx for the help though.. Guess I will give you the points.. hehe Easy 500 huh?
ASKER