Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / ADO.NET / June 2004

Tip: Looking for answers? Try searching our database.

Pooled SQLConnection - Server Disconnection Recovery

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Zohar Massad - 07 Jun 2004 17:47 GMT
I am using SQLConnections, which I know is inheritantly pooled, in my
Serviced Component (COM+) DAL, to access SQL Server (duh).
I am trying to handle the known problem where if the SQL Server is
stopped (disconnected) and subsequently restarted (reconnected) the
first SQLConnection fails with "General network error.  Check your
network documentation."
According to what I've read up, once the first connection fails, the
rest of the zombied connections in the pool are supposedly cleared. So
I catch the error, and try to create a new, second, SQLConnection. The
problem is that sometimes the second connection *also* fails. Its not
consistent, but the first time my DAL is loaded the second connnection
always fails, afterwhich it is usually, but not always OK (sometime
the second new connection succeeds, and sometimes it takes a few more
tries)

When I finish using the connection I always call Close and Dispose. I
also tried calling GC.Collect(System.GC.MaxGeneration); and
GC.WaitForPendingFinalizers(); in my catch, but this did not help.

Can someone please recommend the proper course of action to take when
receiving a network error? It seems wrong to throw an error when the
SQL Server is back online.

Thanks,
Zohar

Below is my pseudo-code:

void ReadData(ref DataObject data, bool retry)
{
try
 {
   using(SqlConnection SQLConn = new SqlConnection(…))
   {
     SQLConn.Open();
     //do work here
     SQLConn.Close();
   }
   catch(SqlException SQLE)
   {
     if (retry)
     {
       GC.Collect(System.GC.MaxGeneration);
       GC.WaitForPendingFinalizers();

       //try once more
       ReadData(ref data, false);
     }
   }
 }
}
Pablo Castro [MS] - 08 Jun 2004 21:44 GMT
Actually, in current versions of SqlClient, we don't clean up the connection
pool when we see the first connection failing because the server was
restarted or any similar reason (yeah, I know...). FWIW, we fixed that in
Whidbey and we'll fail only the first time.

As for alternate solutions, there are not many options for this. One is to
keep calling Open/Execute until it succeeds - at that point all the bad
connections are gone. The other is to force SqlClient to create another
connection pool (for example, if you add an space at the end of the
connection string, it will be considered a different connection string and
thus a different pool will be used).

Signature

Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.

> I am using SQLConnections, which I know is inheritantly pooled, in my
> Serviced Component (COM+) DAL, to access SQL Server (duh).
[quoted text clipped - 47 lines]
>   }
> }
Zohar Massad - 09 Jun 2004 08:20 GMT
> ... keep calling Open/Execute until it succeeds - at that point all the bad
> connections are gone.

Thanks for clearing this up.
What exactly should I look for in the SQLException to make sure it is
this specific situation? Otherwise I might get into an endless loop
when the server is down or there is another permanent SQL problem.

Zohar Masad
PFS - Tradertools

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.