views:

72

answers:

2

I'm trying to debug some resource leaks - oracle connections specifically.

On my local machine, as I step through the Page_Load(), I can see the connections created in the db by monitoring v$session.

As soon as I step out of Page_Load, all the connections are closed.

Same code running on the dev server (W3k, IIS6) does NOT release the resources - connections according to the db are still there.

I've tried this with and without connection pooling enabled, and it's the same - locally it's fine, on the server it leaks.

I have verified that the .net framework is the same in both places & the code is the same as well. What am I missing?

A: 

Whenever you are using limited resources (like database connections) in .NET and are expecting the resources to be cleaned up you should call Dispose() explicitly on the object to ensure that it gets cleaned up and released properly.

As for Visual Studio changing garbage collection, I don't see why it would. The garbage collector may behave differently because you are running on different machine with a different memory profile. You can't expect the the garbage collector to behave in any defined way, especially across machines. But it looks like you have a greater problem of not properly disposing your database connection.

heavyd
Well, I thought we were disposing of everything properly - I'm now trying to explain why the same code works differently on different servers.
chris
+2  A: 

The garbage collector has three different modes of operation: Server GC, Workstation GC Concurrent and Workstation GC Non Concurrent. Each one behaves in a different way and is optimised for different types of applications. This could be what is causing the different behaviour. Specifically, the behaviour can change for a given setting based on whether there is a single or multiple CPUs. Take a look at Tess Ferrandez's blog for a more detailed explanation.

adrianbanks
We actually tested this on three machines and it looks like each was using one of three different scenarios. Thanks for the explanation!
chris