Major Edit:
I misread the article! The comment was in regards to the finalize method of the the class not the finally block :). Apologies.
I was just reading that you should not close or dispose a database connection within a finally block but the article did not explain why. I can not seem to find a clear explanation as to why you would not want to do this.
Here is the article
If you look around, closing the connection in the finally block is one of the recommended ways of doing it. The article you were looking at probably recommended having a 'using' statement around the code that used the connection.
using (SqlConnection connection = new SqlConnection(connectionString))
{
SqlCommand command = connection.CreateCommand();
command.CommandText = "select * from someTable";
// Execute the query here...put it in a datatable/dataset
}
The 'using' statement will ensure the Connection object gets disposed immediately after it's needed rather than waiting for the Garbage Collector to dispose of it.
I have to disagree that you should not close or dispose of a database connection within a finally block.
Letting an unhandled (or even handled for that matter) exception leave open connections can take down a database pretty quickly if it has a lot of activity.
Closing a database connection is the defacto example of why to use the finally statement, IMHO. Of course, the using statement is my preferred method, which is maybe what the original author was going for.
Edit to the Major Edit:
That makes sense now. You wouldn't want to leave closing your database connection up to the garbage collector.
Without the original article, I can't speak for the author. However, depending on how you've implemented instantiating and opening the connection in relation to your try/catch/finally block, you might need to do some additional checking before just calling close. Ex, ensure the connection is not null and not already closed.
EDIT: The article says not to dispose of a connection object in your Finalize method, not to not close it in the finally block. In fact, in the paragraph above it says you should always be closing your connection after you use it, so it is returned to the connection pool.
"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.
Note Do not call Close or Dispose on a Connection, a DataReader, or any other managed object in the Finalize method of your class. In a finalizer, only release unmanaged resources that your class owns directly. If your class does not own any unmanaged resources, do not include a Finalize method in your class definition. For more information, "
http://msdn.microsoft.com/en-us/library/8xx3tyca(VS.71).aspx?ppud=4
A little bit of Googling turns up quite a few pages that hold the opposite opinion. Using a "finally" block seems like a good way to ensure that the connection is always closed correctly, although as others have said I'd be interested to see the original article that said it wasn't a good idea.
From what I can see in the article it advices against calling Dispose or Close in the Finalizer of a class, not against doing so in a finally block, which is quite a different thing.
The Close method puts the connection object into a state from which it can be re-opened. The Dispose method puts it into a state from which it cannot be re-opened (closing it first if currently open).
If you instantiate a connection, open it, use it, then throw it away (the normal usage pattern), then a using block is the best and simplest way to do it.
Obviously, if you are doing something more complex with multiple Open and Close calls, then disposing it will throw a spanner in the works.
Related
Beside's the old known fact that connection.Close() vs connection.Dispose() are the same - except that running Close() over a disposed connection raises an exception while running Close() over a closed connection - is OK - I still have a question :
Assuming connection pooling is on , (default) - why is it important to remember the state of the connection ?
I've read this question here which shows that - avoiding opening and closing a connection saves performance.
This seems logic , but the problem is that the connection is never actually closed ! it is only marked for close.
Even If I use it under a using scope - the dispose just closes the connection and put it back in the pool.
Even if I wanted , I couldn't leave it open ( because I'd want others to use it). so I had to close/dispose it.
Looking at Dapper which also implements this behavior:
public static async Task<IEnumerable<T>> QueryAsync<T>(this...)
{
//...
bool wasClosed = cnn.State == ConnectionState.Closed;
using (var cmd = (DbCommand)command.SetupCommand(cnn, info.ParamReader))
{
try
{
if (wasClosed) await ((DbConnection)cnn).OpenAsync()...
//...
}
finally
{
if (wasClosed) cnn.Close();
}
}
}
As you can see the "memorization" is implemented here.
nb , I already asked Marc about a related topic which is - why in dapper samples he uses both GetClosedConneciton and GetOpenConnection and I got an answer which is to show - that Dapper can deal with both scenarios. However this current question is about why it is re-set the connections state.
Question :
Looking at Dapper code it seems that it remembers the state and re-set the state after operation. ( I also know this behavior from the old sqldataadapter class)
The question is - why ? If I got a closed connection - then, I need to open it. great. but why do I have to close it by condition ? why not ALWAYS close it ? it's not going to hurt performance since the connection is not actually closed - it is only returned to pool.
The other way around - If I got an open connection , then I'd do work and keep it open (huh??)
AS you probably see , I'm missing something here. can someone please shed light ?
why not ALWAYS close it ?
The user could be doing lots of work on that connection. It could be associated with a transaction (closing would orphan it). It could have temporary tables (closing would destroy them), or other connection-preserved state (SET options, impersonation, etc).
Closing a connection here (if it was open originally) would be an unusual and unexpected thing with multiple nasty side-effects.
If you're writing a library function where it makes sense for the consumers to pass you a connection object (of whatever flavour) then the safest thing to do is to respect that connection:
if you're passed an open connection object, make no assumptions about it and certainly don't close it after you've completed your work - you don't know what your consumers have done with it or will do with it.
if you're passed a closed connection object, then you'd better open it before you attempt to use it, and you ought to close it after you're done - you know that your consumer can't have e.g. a transaction open against a closed connection.
If your code creates a connection object, then I'd always recommend that the creation be placed in a using statement and so it will always be closed when you're done.
So, the only remaining thing I can think to say is to think carefully about writing your functions and work out whether it makes sense for your consumers to be passing you connection objects - if your work should always be performed in isolation, it would make more sense to ask for e.g. a connection string and for your code to entirely control the connection.
I'm writing a program that generates Sitemaps. To avoid duplicates I'm using MSSQL Server to store links that are found. during this process It may read and write millions of links and the process of reading and writing may have very little gaps between them (I mean the time between each access to database is very tiny).
I want to know If I can open the connection when the program starts and close it at the end. please consider that creating some sitemaps may take days to finish. Or is it wise to open and close connection each time I want to access the db?
By the way, I'm using sql server locally.
The answer to your question is the Connection Pooling feature.
It is always preferable to open the connection just when needed, access your data, close and dispose the connection immediately
Indeed a specific work pattern exists
using(SqlConnection con = new SqlConnection(.....))
{
... do your work with the database here ....
}
The using statement ensures that the object created at the opening is closed and disposed at the closing braces. Even if an Exception occurs in database code.
This doesn't mean that you cannot try to optimize your code. For example you could gather a few of sitemaps together and write them in just one shot, but usually it is best to follow a simple work pattern, finish the work as soon as possible and worry for optimization later.
You can work with the following code :
SqlConnection conn;
try
{
conn = new SqlConnection(_dbconnstr));
}
catch
{
//exceptions are bubbled
throw;
}
finally
{
//Dispose is always called
conn.Dispose();
}
hope this helps!
I usually open and close connection each time I use it.
Releasing resources must be done when there is many connections around.
If you are the only one, you might keep your resources.
Be aware of setting timeout connection.
Good luck guy!
It is better to open/close the connection. There is no benefits in kipping connection open. ADO.NET Connection pooling (which is on by default) will take care of which connection to close and when.
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.
If you know it's going to take a while, what about writing to a local data table and then when you reach a threshold, write all the records to the database.
Or even write the info to a local file (format of your choice) and then write that file to the database in one shot (or multiple shots if you want to do it every x records or y minutes.)
Back to basics.
I have an application written in c# and I am using the sqlClient to connect to database.
I have several methods and I usually open the connection in a try catch block
try{
**open connection**
//Mehod1()
//Method2()
........
}catch(exception){
//Do something
}finally{
**close connection**
}
The Problem is that there are a lot connections in pool.
I am using master page and in master page I am loading the menu from database (different menu for each user).
Then in main pages I open again a connection to get the rest data.
In the middle of the page it may be a method that need again to connect to database.
My Question is
Is this a good practise?
Am I doing something wrong?
Is there a better practise to avoid multiple connections?
What about singleton pattern?
Thanks in advance
SOLUTION
I found the reason!!!
I had forgot to close a connection.
I was sure that I had close it, but
sometimes you can't be so sure.
Thanks everyone for your responses
Since the connection is pooled you don't need to "reuse" it in different methods.
I use the following code:
using(SqlConnection connection = new SqlConnection("your-connectionstring"))
{
// Do your stuff here...
}
Using is just a short hand way of writting try-catch-finally. It is used for disposable objects.
And this can go into each method.
EDIT: Using the connection from the pool is not hurting performance either. All connection information are cached anyway. So just use the SqlConnection on an atomic level.
It's a good thing though to have the ConenctionString handling in a more generic way...
Using() as said above is a good way to new up a new object of a class that implements IDisposable. But with that being said , you cannot leave you connection open once you done. You have finite number of connection in the pool and leaving a connection unclosed can starve other SPIDs which are waiting for active connection which will finally timeout. So you should
Always have atomic and small transactions .
Close when done.
There is DAAB (data access application block) from Microsoft Enterprise Library which can be used as helper to open and close connections + do many other DB related tasks easily. Here it is
http://msdn.microsoft.com/en-us/library/cc511547.aspx
Probably you didn't dispose your SqlConnections
try this:
using (SqlConnection connection = new SqlConnection(connectionString))
{ }
this syntax will call method Dispose() automatically for you. Using statement details here
UPDATE:
A bit more info about this methods you may find here: Close, Dispose
Basically the difference is that method Dispose() called method Close(), but before it is cleaning some resources and removing connection from the pool details here.
As you see Dispose() doing a bit more than Close(). So if you going to reuse connection later use method Close() if not destroy that completely using method Dispose() which is automatically getting called if you using the syntax above.
I was trying to explain to someone why database connections implement IDisposable, when I realized I don't really know what "opening a connection" actually mean.
So my question is - What does c# practically do when it opens a connection?
Thank you.
There are actually two classes involved in implementing a connection (actually more, but I'm simplifying).
One of these is the IDbConnection implementation (SQLConnection, NpgsqlConnection, OracleConnection, etc.) that you use in your code. The other is a "real" connection object that is internal to the assembly, and not visible to your code. We'll call this "RealConnection" for now, though its actual name differs with different implementations (e.g. in Npgsql, which is the case where I'm most familiar with the implementation, the class is called NpgsqlConnector).
When you create your IDbConnection, it does not have a RealConnection. Any attempt to do something with the database will fail. When you Open() it then the following happens:
If pooling is enabled, and there is a RealConnection in the pool, deque it and make it the RealConnection for the IDbConnection.
If pooling is enabled, and the total number of RealConnection objects in existence is larger than the maximum size, throw an exception.
Otherwise create a new RealConnection. Initialise it, which will involve opening some sort of network connection (e.g. TCP/IP) or file handle (for something like Access), go through the database's protocol for hand-shaking (varies with database type) and authorise the connection. This then becomes the RealConnection for the IDbConnection.
Operations carried out on the IDbConnection are turned into operations the RealConnection does on its network connection (or whatever). The results are turned into objects implementing IDataReader and so on so as to give a consistent interface for your programming.
If a IDataReader was created with CommandBehavior.CloseConnection, then that datareader obtains "ownership" of the RealConnection.
When you call Close() then one of the following happens:
If pooling, and if the pool isn't full, then the object is put in the queue for use with later operations.
Otherwise the RealConnection will carry out any protocol-defined procedures for ending the connection (signalling to the database that the connection is going to shut down) and closes the network connection etc. The object can then fall out of scope and become available for garbage collection.
The exception would be if the CommandBehavior.CloseConnection case happened, in which case it's Close() or Dispose() being called on the IDataReader that triggers this.
If you call Dispose() then the same thing happens as per Close(). The difference is that Dispose() is considered as "clean-up" and can work with using, while Close() might be used in the middle of lifetime, and followed by a later Open().
Because of the use of the RealConnection object and the fact that they are pooled, opening and closing connections changes from being something relatively heavy to relatively light. Hence rather than it being important to keep connections open for a long time to avoid the overhead of opening them, it becomes important to keep them open for as short a time as possible, since the RealConnection deals with the overhead for you, and the more rapidly you use them, the more efficiently the pooled connections get shared between uses.
Note also, that it's okay to Dispose() an IDbConnection that you have already called Close() on (it's a rule that it should always be safe to call Dispose(), whatever the state, indeed even if it was already called). Hence if you were manually calling Close() it would still be good to have the connection in a using block, to catch cases where exceptions happen before the call to Close(). The only exception is where you actually want the connection to stay open; say you were returning an IDataReader created with CommandBehavior.CloseConnection, in which case you don't dispose the IDbConnection, but do dispose the reader.
Should you fail to dispose the connection, then the RealConnection will not be returned to the pool for reuse, or go through its shut-down procedure. Either the pool will reach its limit, or the number of underlying connections will increase to the point of damaging performance and blocking more from being created. Eventually the finaliser on RealConnection may be called and lead to this being fixed, but finalisation only reduces the damage and can't be depended upon. (The IDbConnection doesn't need a finaliser, as it's the RealConnection that holds the unmanaged resource and/or needs to do the shut-down).
It's also reasonable to assume that there is some other requirement for disposal unique to the implementation of the IDbConnection beyond this, and it should still be disposed of even if analysing the above leads you to believe its not necessary (the exception is when CommandBehavior.CloseConnection passes all disposal burden to the IDataReader, but then it is just as important to dispose that reader).
Good question.
From my (somewhat limited knowledge) of the "under-the-hood" working of a SQL Connection, many steps are involved, such as:
The Steps Under the Hood
Physical socket/pipe is opened (using given drivers, eg ODBC)
Handshake with SQL Server
Connection string/credentials negotiated
Transaction scoping
Not to mention connection pooling, i believe there is some kind of alogrithm involved (if the connection string matches one for an already existing pool, the connection is added to the pool, otherwise new one is created)
IDiposable
With regards to SQL Connections, we implement IDisposable so that when we call dispose (either via the using directive, or explicity), it places the connection back into the connection pool. This is in stark contrast with just the plain old sqlConnection.Close() - as all this does is close it temporarily, but reserves that connection for later use.
From my understanding, .Close() closes the connection to the database, whereas .Dispose() calls .Close(), and then releases unmanaged resources.
Those points in mind, at the very least it is good practice to implement IDisposable.
Adding to answers above... The key is that upon "opening the connection" resources may be allocated that will take more than standard garbage collection to recover, namely an open socket/pipe/IPC of somekind. The Dispose() method cleans these up.
I am studying asynchronous C# Sockets at the moment and i have noticed something that i am confused about.
In all the End...(Accept/Connect) etc there is a code section like:
Socket s = (Socket) ar.AsyncState;
Here it is being casted as a socket.
As each End uses these local Sockets is there any point in trying to close() any of them once I am done?
What is the best practice?
Most authors seem to agree that if something implements IDisposable, you should call Dispose. The easiest way to do this is to use 'using' which automatically calls Dispose for you.
using (DirectoryEntry de = new DirectoryEntry(path))
{
.... some code
}
I think the best practice for sockets is similar to that for the streams. I personally always use the close() methods in both - sockets and streams. If something has been opened, it should be properly closed :)
It will get closed eventually even if you don't (when the garbage collector kicks in), however best practices dictates that you close handles to objects when you no longer need them.
Consider file streams, not closing a file stream can mean that data will not be wrote to a file. Sutble problems like this can occur if you do not explicity close the handle of objects that should be closed.
Closing your sockets is critical. Just because you don't notice any ill effects in a particular Framework version doesn't mean in future implementation the Framework might leave resources in use until it is closed. You most likely are leaving resources in use on the system as well. Plus, it doesn't hurt. :p
The object probably does free its resources and implictly close the socket when it is destroyed, but with a automatic garbage collected environment like C#, you never know when that might happen.
Either by using the
using(Socket s)
{
...
}
or by using socket open and at the end closing the socket.
If you leave a socket opened and try to open it again somewhere else then a runtime error will occur...
All streams dataReaders, connections must be closed.
the main reasons seem to be:
1. security
2. waste of memory
3. prone to runtime errors
I suggest either Disposing or Closing the stream after you are done. This allows the system to immediately free the network resources once you are done with your socket.
If you are using the socket from a single function, the using statement works well as it implicitly disposes your object. Otherwise (for example when keeping a socket active, maintaining a reference to it in an object), you will want to either call Close() or Dispose() when you are done. Otherwise, the socket could stay open indefinitely. Dispose() may be a slightly better choice because it frees more resources than a Close() would.
MSDN may skip the Close because the socket will be automatically closed at the termination of the process when the remaining resources are garbage collected.
Socket.Close calls Dispose. Calling Dispose, either explicitly or implicitly, on an IDisposable object is obligatory. The IDisposable interface is for objects that use unmanaged resources, so allowing the object to be garbage collected without calling dispose will result in resource leaks. A short sample program may not show this problem, but a full, long running problem will certainly run into problems.