A while back I wrote an ORM layer for my .net app where all database rows are represented by a subclass of DatabaseRecord. There are a number of methods like Load(), Save() etc. In my initial implementation I created a connection to the DB in the constructor of DatabaseRecord e.g.
connection = new SqlConnection(
ConfigurationManager.ConnectionStrings["ConnectionName"].ConnectionString
);
I then call Open() and Close() on that SqlConnection at the beginning and end of my methods which access the database. This seemed to me (as someone who was familiar with programming but new to c# and .net) to be the most efficient way to do things - have one connection and open/ close it where necessary within the class.
I've just been doing some reading though and it appears that this pattern is recommended in a number of places:
using (var connection = new SqlConnection(...)) {
connection.Open();
// Stuff with the connection
connection.Close();
}
I can see why it's desirable - the connection is automatically Dispose()d even if the stuff you do in the middle causes an uncaught exception. I was just wondering what the overhead is for calling new SqlConnection() potentially many times like this.
Connection Pooling is on so I imagine the overhead is minimal and the second approach should be best practice but I just wanted to make sure my assumptions are right.
Yes, it is best practice. The using makes your call to Close() exception-safe.
And the overhead of creating a (any) object is indeed minimal, and smallest for short-lived objects (that stay in GC generation 0).
Note that you don't have to call Close() at the end of the using-block anymore, it is automatically done for you (Dispose==Close).
This is partially a matter of taste. As long as you employ connection pooling the overhead of creating a new (recycling a pooled connection) will be minimal, so generally the recommended pattern is to create new connection objects as needed.
If you run several commands immediately after each other then I see no reason to create new connections for each of them, but you should avoid holding on to open connections for a long time.
Also, you should note that the Dispose method will close the connection for you. So there is no need to call both Close and Dispose. Since the using clause will call dispose when it ends there is normally no need to call Close.
If you're unsure about the cost of opening/closing connection, have the SqlConnection a member variable of your class, but make the class IDisposable and dispose of the SqlConnection when the class is disposed
Related
How are the connections handled in a single transaction when we open close connections for each statement in C#?
The scenario is with the same connection string and the connection is opened and closed multiple types, once for every statement.
Consider the following example
void updateSomething() {
using (SqlConnection connection = new SqlConnection(
"Integrated Security=SSPI;Initial Catalog=Northwind"))
{
connection.Open();
// Execute the statements
connection.Close();
}
}
When I'm executing the following code:
void SomeMethod()
{
using(TransactionScope scope = new TransactionScope())
{
for(int i=0; i < 10; i++)
{
this.updateSomething();
}
scope.Complete();
}
}
The recommendation is to use a connection Open/Close for each statement. That is because we are not actually creating connections, we are just using one from the pool.
Why is this the case? I get it that we hold the connection for as little time as we can, but the thing is that in most transactions, we are going to get it in the next moment during the next statement.
Is it only to avoid the demanding code computation time in between the statements if some such exists (which it shouldn't as it would lock the database in the transaction state for much longer that needed).
Wouldn't it make sense to keep one connection open for the duration of the transaction?
The recommendation is to use a connection Open/Close for each statement.
Without seeing that comment in context, I'm guessing this recommendation is because of what you said: creating and destroying a SqlConnection objects does not mean you are creating and destroying network connections.
I think the motive behind "use one for each statement" is to just not worry about trying to be efficient about when you create SqlConnection objects. Don't go out of your way to keep one alive and pass it around all throughout your code thinking you are avoiding tearing down a network connection. There's just no point.
In your example, it won't really make a difference. You can use the same SqlConnection object for each query if you'd like, as long as you are making them sequentially and not in parallel. It's probably even slightly more efficient since you save the computational time of creating an SqlConnection object. But that saved time will likely not even be noticeable.
Well, I would like to know what is the possible problems about use the following approach
CreateContextFactory().Create().QueryOpenConnectionCount();
instead of:
using (var context = CreateContextFactory().Create())
{
openConnectionCount = context.QueryOpenConnectionCount();
}
return openConnectionCount;
and also if there is any problem about something like:
CreateContextFactory().Create().QueryOpenConnectionCount1();
CreateContextFactory().Create().QueryOpenConnectionCount2();
CreateContextFactory().Create().QueryOpenConnectionCount3();
This is because I have some methods in a class that are open db contexts as above, I could create a using statement for them, but so I would need to pass the context for all methods, and I would also need to refactor a helper that executes a transaction using a db context (because it creates its own context internally). So what are the problems about let the code stay this way?
Often, a data-context "owns" a connection, to avoid constantly having to fetch one from the pool and initialize it. Disposing the data-context typically disposes that connection.
So: if you keep creating data-contexts without properly disposing them, you're hemorrhaging connections, at least until GC steps in and undoes the mess (releasing the unmanaged part of the connection back into the unmanaged pool, if there is an unmanaged part).
This is a bad thing, and severely limits scalability and increases the number of open connections to your database server. So yes, you should dispose your data-contexts. Extending that to the general case: you dispose any IDisposable thing that you're responsible for, when you're done with it. With perhaps a few exceptions (HttpClient, DataTable, etc).
Note that C# 8 has a slightly terser (I would say "nicer", but that is subjective; I like it a lot) syntax for this, if your using statement reaches to the end of the current scope (i.e. to the next }):
using var context = CreateContextFactory().Create();
return context.QueryOpenConnectionCount();
or even with earlier C# you can make it simpler and remove the local:
using (var context = CreateContextFactory().Create())
{
return context.QueryOpenConnectionCount();
}
When implementing the repository pattern using Dapper ORM I am currently doing the following:
private readonly ConnectionStrings _connectionStrings;
private IDbConnection _db;
public CustomerRepository(IOptions<ConnectionStrings> connectionStrings)
{
_connectionStrings = connectionStrings.Value;
_db = new SqlConnection(_connectionStrings.DefaultConnection);
}
public Customer Find(int id)
{
return this._db.Query<Customer>("SELECT * FROM Contacts WHERE Id = #Id", new { id }).SingleOrDefault();
}
Can someone please tell me if I should be doing it this way or if I should be using a using statement with a new SqlConnection in every single repository function.
I am assuming my above code will need something like UnitOfWork to be effective right? And also some way of disposing the connection when done running all of the repository functions needed.
The recommended approach is to use using statements. User paulwhit explained their usage great in this answer:
The reason for the "using" statement is to ensure that the object is disposed as soon as it goes out of scope, and it doesn't require explicit code to ensure that this happens.
The essential difference between having using statements in your methods and having the connection be a class member is that the using statement makes sure that once you're done with your operations, and have exited the block, your connection is closed and disposed of properly. This removes any possibility of error on the part of the developer, and generally makes everything neater.
An important additional benefit of the using statement in this situation is that it ensures the connection is disposed of, even if there is an exception (though it is worth noting that this isn't strictly the only way to achieve this). According to the documentation:
The using statement ensures that Dispose is called even if an exception occurs while you are calling methods on the object.
If you were to have the connection be a class member, then an unhandled exception in the middle of a method that caused your program to exit early would possibly leave the connection open. This is of course not a good thing.
So to sum up, unless you have a very good reason not to, go with the using statement.
In general when a type implements IDisposable (and hence works with using) it can sometimes be useful to wrap it in another type, having that other type also implement IDisposable and have its Dispose() call the wrapped object, and then use using (or another mechanism to call Dispose()) on it.
The question is whether this is one of those sometimes.
It's not. In particular note that SqlConnection implements pooling behind the scenes, so (unless you explicitly opt-out in your connection string) instead of Dispose() shutting down the entire connection to the server what actually happens is that an object internal to the assembly of SqlConnection that handles the details of the connection is put into a pool to use again the next time an SqlConnection with the same connection string is opened.
This means that your application will get as efficient use of as few connections as possible over many uses of the SqlConnection class. But you are stymying that by keeping the connections out of the pool by not returning to the pool as promptly as possible.
If I am calling some data access methods from multiple threads, do I need to lock the code around the DB calls to ensure consistency, or are the using statements below atomic?
public static DataRow GetData(Int32 id)
{
using (SqlConnection con = new SqlConnection(connectionString);)
{
con.Open();
SqlCommand cmd = ...
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add(...)
cmd.Parameters.Add(...)
DataTable dt = new DataTable();
return new SqlDataAdapter(cmd).FillWithRetry(dt, sqlGetEmail.CommandText);
}
}
I don't think one thread can affect the connection object defined and 'in use' from another.
Using statements have nothing to do with thread-safety (or lack of).
They merely ensure that Dispose method of the used object is called when the block ends; but are otherwise equivalent to a manual try..finally Dispose.
In this particular case: since a new connection is opened on each thread then it is 'thread safe'. It still might not be atomic wrt. the database or other shared state.
I don't think one thread can affect the connection object defined and 'in use' from another.
So I suppose you are worrying your connection's concurrent access. The using statement is not a lock. If you want to use exclusively a connection or any other instance you should use:
lock(myConnection)
{
// your code
}
What the using keyword is for that's described here
However I think there is other misunderstandings here:. In your example your connection is a local variable what is instantiated as many times as the control flow enters to your GetData method (even in different threads). So even the control flow reenters multiple times (and in different threads) to the method, no shared connection instance will be used, each entering to the method creates its own instance.
It would be different the case if the connection instance would be a parameter. Then you should worry about concurrency, and use a lock.
Conclusion: In your sample you do NOT need to worry about your connection instance concurrent access, and you do not need to use any locking semantics.
Interestingly in your sample using of using is indeed correct, because Connection is IDisposable, so you should apply a deterministic dispose guard around its usage with try/finally or better with its shortcut: the using keyword.
What is the difference between these two cases. Firstly, if I open the connection and pass it into my method as a parameter, compared to opening the connection directly in the method?
cnn.open()
func(cnn,param1,param2);
vs
func(cnn, param1,param2)
{
cnn.open();
//open connection here
}
There's no difference from the code you've posted other than in one case, your calling function needs to take care of opening/closing the connection, in the other, you'd expect the function to do it.
The difference is that in the second method, you open the connection.
In the first method you expect the method to only use a connection not caring about cleaning up the resources.
No functional difference but the lines for opening and closing a connection should usually be as close together as possible hence they should be in the same method.
The difference is in how you want to use the connection and performance. If the function is a once off call and you are calling no other functions, or not doing anything else with the connection, then the second version of the function could even be reduced to:
func(param1, param2) {
Connection c = ....
c.Open(...);
...
c.Close();
}
However if you are calling many functions on the connection, even calling the function many times on the connection or if the creation and configuration of the connection is at a higher layer in your code, then you should use the first version of the function, with the addition of throwing an exception if the connection is not opened.
Well, I think you shouldn't ask for the different rather you should explain the situation you are in and ask for recommendation for what case must be used.
Anyway, As Everybody told you In case 2 the connection object and its life cycle is encapsulated within the callee function. This is recommended if database operation out side this function is not desired.
Otherwise if you have any other database activity to be done out side this function scope like in caller function or any other function(other than func) being called from caller function then you should use the Case 1.