SQL Connection Pool stops AppDomain unloading

  • Thread starter Thread starter Mike Williams
  • Start date Start date
M

Mike Williams

For some days now we have been trying to get to the bottom of an issue with
a simplified version of our real application. In brief we have a Master
object within a main AppDomain which is responsible for spawning a Slave MBR
object in a newly created AppDomain upon request. When the Slave finishes
its work, it informs the Master (using a standard remoting MBR call on a
shared interface) and the Master begins the process of spawning a new Slave
and tearing down the AppDomain of the previous slave.

So far as the description stands above, all is well and the Slave object and
its hosting AppDomain are unloaded gracefully. However, if we create a
SqlConnection object (in either Master or Slave AppDomain) and simply Open
it then Close it immediately (never even bothering to read/write any data),
the above AppDomain unloading stops working and we start to build up a
number of AppDomains trying to be unloaded. To solve this situation, we have
found that if we explicitly turn off the Sql Managed Provider's connection
pooling (using Pooling=False in the connection string) then it goes back to
working again.

Why we are puzzled though is this: Does the SqlConnection Pool hold onto
some unmanaged resources/code which, whatever AppDomain it is created in
(implicitly by creating a SqlConnection object), any AppDomain cannot be
unloaded as the unmanaged resources/code do not actually belong to the
AppDomain, but to the overall Process?

Clearly we can get round the problem at the cost of some performance by
turning Connection Pooling off, but we would like to know whether this is
our only option.

Thanks in advance
Mike
 
Well, after some further investigations by a colleague, he had found that even with Connecction Pooling off, he could still get into the state where the AppDomains could not be unloaded and traced it down to the use of RemotingServices.Configure(). Thus sparked off a memory of reading an article on the GenuineChannels website (http://www.genuinechannels.com/Content.aspx?id=88&type=1) where others reported memory leaks in Framework 1.1 associated with this call. The recommended approach was to remove the apparantly innocuous [STAThread] attribute from the Console Server code. As our simple example also used a simple console app. we had that attribute too. After taking it off and then allowing Sql Connection Pooling on again, the AppDomain was unloaded happily several times.

This little attribute adorned by the Visual Studio macro seems to be the culprit. MSDN states

COM threading models only pertain to applications that use COM interop. Using this attribute in an application that does not use COM interop has no effect.

however this seems not to be the case for us.

Any comments would be gratefully received.

Mike
 
Back
Top