@usr and I are having a disagreement in another question about whether or not .NET will scavenge open connections that have been idle, but still maintain a held reference.
I maintain, based on documentation, that if the physical connection is idle for a period of time, it will be reclaimed after a period of time even if a SQLConnection object reference remains held.
usr claims that this won’t happen, and it only reclaims connections that no longer have references. His assertion as this would make connection pooling unreliable and would cause havoc with transactions.
I will admit, the documentation is vague about the issue of held references.
I’m looking for an authoritative answer on this, not just guessing. Either someone has experimented and proven either case, or someone with knowledge of the internal workings.
So which one is it?
EDIT:
I think the confusion here is with the terminology of “Closed”. What appears to be the case is that the documentation refers to closing the physical connection as “Removing” the connection from the pool. While “Closing” refers to releasing the open physical connection back into the pool for re-use.
Open connections can still be aborted, but it’s unclear if the pooler marks this as invalid if it’s still held as open by the client app (ie client app has not yet called close on the aborted connection) Not sure it really matters though, other than as part of the pool count.
I can tell you with 100% certainty that the connection DOES NOT return to the pool until released. I had a session create a temporary table, and left it hanging while waiting for user input. The user comes back after 6 minutes, presses a button and it continues on the same SPID and life goes on against the temporary table.
Applying logic, it makes sense because can you imagine the havoc if you lose the SPID just because you’ve been idle for X minutes? Should you keep having to “ping” SQL Server with a command just to keep it alive? (it would be insane)
You appear to be confusing 2 concepts. When a Connection is closed, it returns to the pool. If it goes out of scope, it is implicitly closed -> returns to the pool. The reference to “idle” refers to when the connection in the pool becomes idle, not when it’s actively referenced and not closed. A held connection isn’t even in the pool to become eligible for any type of scavenging. Freeing resources from the pool makes sense, because a web-app can easily burst to 100s of connections, then for the next few months stay at around 20 or so active concurrent connections.