If you know you are going to be working for a long time in your app where the
connection is not necessary, pull the data, churn and then stick it back in.
That would be one solution (for both 1.1 and 2.0). This might require major
refactoring to accomplish.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
***************************
Think Outside the Box!
***************************
"Trevor McClean" wrote:
> Hey guys,
>
> Came across this issue a few days ago and it has taken me a long time
> (and a lot of frustration) to track down. I am working on a mission
> critical application which must continue to execute when a connection to
> the database server is lost (for any reason). While performing some
> testing on this issue, I noticed it was taking my application a long
> time to reconnect to the database after the server was available again.
> I did some digging, and a little bit of reflection (in multiple senses
> of the word). I noticed that the connection pool will not attempt to
> actually reconnect until a specified period has elapsed.
>
> This period starts at 5 seconds and doubles on every failed connection
> attempt (not in the previous period since no connection is actually
> attempted). This period does not get reset until a successful
> connection is made. This means that a database which is down for
> several hours could take several hours to reconnect after it has been
> successfully started again.
>
> I verified that it is fixed in .NET 2.0 and limited to 60 seconds but
> there does not seem to be a fix for 1.1. Does anybody know of a work
> around for this issue?
>
> Trevor
>
|