|
You're exactly right about closing the connection. That is a major issue as the connection will never be destroyed in the pool. As far as I know min & max pool size are attributes exclusive to the SqlClient.
What ODBC driver are you using? I'd research the inability to close the connection before diving too deep into the pooling side of things. Pooling on or off not being able to close/dispose the connection is troubling.
That being said, below are some notes on my experiences with pooling.
I've read somewhere that it is possible to enable & disable connection pooling via the ODBC administrator. I've got version 3.5 of the administrator & all I can do is enable or disable the performance monitor & set the retry wait. I would recommend turning on the performance monitor & reviewing the entries made. If you search MSDN you can find articles about reading the performance monitor for the connection pooling entries.
One way to make completely sure that you've got the connection pooling turned off is to check in the registry under:
HKEY_LOCAL_MACHINE\Software\ODBC\ODBCINST.INI\ XXXXXX (where XXXXXX is the driver name.)
If Connection pooling is truely turned off there will not be a string value for CPTimeout.
The connection pooling should be managing itself. Once you close the connection it should release it back into the pool & once the connection has reached its timeout (CPTimeout above...defaults to 60 seconds) its destroyed. If your application appropriately disposes of all connections the connections will eventually be destroyed. Using the performance monitor you can track this process.
An easy way to check & see if connections are actually being left open is by calling ReleaseObjectPool (System.Data.Odbc.Odbcconnection). If any connections are still open calling this will do nothing. However, if all connections are closed this call will destory any idle connections in the pool.
Hope this helps. -Nick
|