I
Ignacio Machin \( .NET/ C# MVP \)
Hi,
Yes, A Reader is a server base forward only cursor. It use a dedicated
connection. That;s why it has an overloaded method that indicate to close
the connection when SqlDataReader.Close is called.
Both, they are two differents.
If an exception is throw and you did not use a using block or a finally
then you have a problem.
QOUTE FROM MSDN:
CAUTION:
It is recommended that you always close the Connection when you are
finished using it in order for the connection to be returned to the pool.
This can be done using either the Close or Dispose methods of the Connection
object. Connections that are not explicitly closed might not be added or
returned to the pool. For example, a connection that has gone out of scope
but that has not been explicitly closed will only be returned to the
connection pool if the maximum pool size has been reached and the connection
is still valid.
END QUOTE
As you can see it might not be returned. so you better close all those
connections always !
The pool itself is private to the Sql provider, there is no way AFAIK to
access it from the exterior , nor that you need it, if you follow the rules
using the connections as suggested you should be ok
Brett Romero said:and stored back in the pool.
Let's say I run an ad hoc query and created the connection via the
"using" statement. During the time that query is running, a data
reader opens, using the same connection string. This is two
connections from the pool right?
Yes, A Reader is a server base forward only cursor. It use a dedicated
connection. That;s why it has an overloaded method that indicate to close
the connection when SqlDataReader.Close is called.
Once both have completed, they are disposed via the using statement.
Are both returned to the pool or just one since they are identical?
Both, they are two differents.
It would seem feasible to have both in the pool hanging around to avoid
blocking when two connections are needed, which is a high probability
for most apps...I'd think. Especially if a block of code throws an
exception and doesn't dispose of the connection. What happens to the
connection than?
If an exception is throw and you did not use a using block or a finally
then you have a problem.
QOUTE FROM MSDN:
CAUTION:
It is recommended that you always close the Connection when you are
finished using it in order for the connection to be returned to the pool.
This can be done using either the Close or Dispose methods of the Connection
object. Connections that are not explicitly closed might not be added or
returned to the pool. For example, a connection that has gone out of scope
but that has not been explicitly closed will only be returned to the
connection pool if the maximum pool size has been reached and the connection
is still valid.
END QUOTE
As you can see it might not be returned. so you better close all those
connections always !
Where exactly in the framework is the connection pool? Where are some
references on that?
The pool itself is private to the Sql provider, there is no way AFAIK to
access it from the exterior , nor that you need it, if you follow the rules
using the connections as suggested you should be ok