views:

1249

answers:

2

Sorry if this is a duplicate, i've read many questions that are either very similar or require roughly the same keywords to describe (but aren't quite the same)...

situation: an asp.net application has a connection pool memory leak problem (where connections are not being closed correctly for example)...I need clarity on the following:

Does recycling the application pool clear the connection pool (thus allowing more connections to be made)?

If the connections are left in memory until the Garbage Collector removes them...does this happen when the application pool is restarted (or are/can they left beyond that)? I also understand the Garbage Collector could clean them up at anytime as well...but are they still in use and unable to be collected until a reset or application pool restart?

i'm reviewing a system and the end goal is obviously to have the code corrected to manage the connections correctly, but i'm trying to gain more of an understanding about the garbage collection/application pool process...

Thanks heaps!

+2  A: 

Yes, recycling the app pool kills and restarts the IIS process responsible for running your application. All resources are freed at this point, simply because the process is exiting.

If the process is never restarted and simply leaks handles, the garbage collector will eventually clean them up. However, it's likely that you'll run out of handles for whatever resource is leaking before this happens. This is why it's important to call Dispose() on these objects(preferably by the "using" pattern) so that the resources are freed as soon as the app is done with them and not when the garbage collector gets around to it.

Jesse Weigert
A: 

A connection pool is a cache of database connections. An application pool is one (or more) worker processes. So, when you shut down the application pool you are shutting down your worker processes and starting up new worker processes; this will result in the pool being destroyed and all connections in the connection pool being closed.

If you do not call Close or Dispose on a connection and rely on the garbage collector then the connection may or may not be returned to the pool. I think it will only be added back to the pool if the connection is still valid and the maximum pool size has been reached. As you probably know, you should never rely on the garbage collector for this. An easy way to ensure the connection is Disposed is to use the using statement which will automatically call Dispose at the end of the code block.

In ADO.NET 2.0 there are new methods to programmatically manage the pools: ClearAllPools and ClearPool. This might help you with your problem until you can fix all of the data access code.

Tuzo
lucky for me i won't be the one having to do the fixing! the real problem is the excessive use of datareaders in the application...there are no try/catch/finally blocks so if an error occurs when the dispose code never runs and the connections get used up...
davidsleeps
That's what it sounded like...it's funny/sad how the same mistakes show up again and again.
Tuzo