Guy Smith-Ferrier's article, "SqlClient Connection Pooling Exposed" (.NETDJ, Vol. 1, issue 12, www.sys-con.com/dotnet/article.cfm?ID=483), generated a question from reader Angel Saenz-Badillos.

Most Interesting Pooling Article I Have Seen
This has to be the most interesting article on managed pooling I have seen. I like the fact that you not only show the solution but warn people that modifying internal state is not guaranteed to work across releases.

I have been working with Appdomains unloads; these are very important for applications that host the URT, like the new version of SQL Server, and of course, IIS has been using this ever since we shipped v1.0.

It is definitely a drastic solution, but it works well as a stopgap measure, and it would be a version-friendly solution for this problem. I would be interested in hearing more about why you feel that this is not a good solution and would like to hear from people using this feature in their applications.
Posted by Angel Saenz-Badillos
on Dec. 11 @ 12:33 PM

The author responds:
Thanks! It is a subject I found very interesting, and as you can see, I'm not keen on being told that I can't do something.

Regarding unloading the AppDomain, in terms of achieving the result (of being able to flush the pool), it gets 10 out of 10. No problem there. For me, the problem lies in the upheaval to the application code itself. If you have created a set of business objects and have encapsulated access to the database through the business objects, then the upheaval will be partially limited to modifying those business objects. Obviously, the line instantiating the new objects will change from, say:

CustomersBusinessObject customers = new CustomersBusinessObject();

to:

CustomersBusinessObject customers = (CustomersBusinessObject)
appDomain.CreateInstanceFromAndUnwrap("MainApplication.dll",
"MainApplication.CustomersBusinessObject");

but if you have an object factory of some kind, then you have already encapsulated the code for object instantiation, so this might not be an issue.

The big issue with this approach is that if developers haven't written their applications to expect to communicate with objects across domain boundaries, then they will be in for a bit of a learning curve. So if a developer has written a straight client/server Windows Forms application and attempts to use the approach of unloading the application domain, they will find differences in behavior that they weren't expecting.

For example, if the business object has a method called Update to which you pass a DataSet, then in a regular single-AppDomain application there is only one copy of the DataSet and when the DataAdapter's Update method is called, the DataRows in the DataSet will have their RowState updated to reflect the change to the database. If the business object came from a different AppDomain, there would be two copies of the DataSet. The copy of the DataSet in the business object's AppDomain would be updated correctly, but these changes wouldn't be seen in the host application's copy of the DataSet. Thus, after calling the business object's Update method, the DataSet in the host application would still think that there are changes to be made to the database. Furthermore, it wouldn't have picked up any changes made to primary keys, foreign keys, and other updates.
Posted by Guy Smith-Ferrier on Dec. 14 @ 03:05 PM

Send us your feedback. Letters may be edited for length and clarity. Please provide full name, location, and, if applicable, title, and company.
dndj@sys-con.com