Yesterday I asked a question yesterday about What is the difference between implementations of IDisposable?
I was implementing a class to help get instances of SqlConnection
, SqlCommand
, SqlDataReader
methods ExecuteSql
etc. And when I implemented the IDisposable
interface I saw some things I do not know about memory management in .Net.
This also reminded me of the fact that I was implementing a class for the same purpose and that I ended up including the Connection String option with Pooling=false
because I was having problems doing the Dispose
of instances of SqlConnection
even after the actual completion of the request cycle.
When I did this I had a class something like this:
public class DbConnection : IDisposable
{
private SqlConnection connection;
public DbConnection()
{
connection = new SqlConnection("string de conexão");
}
#region outros métodos ...
~DbConnection()
{
Dispose();
}
public void Dispose()
{
if (connection != null && connection.State == ConnectionState.Open)
{
connection.Dispose();
connection = null;
}
GC.SuppressFinalize(this);
}
}
This is similar to the other question I created.
I was researching that I found comments about this Connection Pool and that by using Dispose()
explicitly SqlConnection
we could be causing confusion in the Connection Pool control. Finally, one solution would be to disable the Connection Pool.
Allow connection pooling beneficial to application performance?
Allowing Connection Pool, what is the correct way to manage instances of SqlConnection
, not doing Dispose()
?
By default SqlConnection allows only one SqlDataReader per instance of SqlConnection, right, to get more than one you need to add the MultipleActiveResultSets=True;
option in the Connection String, does this cause performance loss in the application?