Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What SQL Connection object is and what does actually happen when we open/close it? What resources does it consume and why is it necessary to dispose it (in terms of c#/.net)?
SqlConnection:
Take a look at the MSDN page for SqlConnection. It is stated that:
A SqlConnection object represents a unique session to a SQL Server
data source. With a client/server database system, it is equivalent to
a network connection to the server.
SqlConnection.Open: In the MSDN page on SqlConnection.Open, it is stated that:
The SqlConnection draws an open connection from the connection pool if
one is available. Otherwise, it establishes a new connection to an
instance of SQL Server.
SqlConnection.Close(and Dispose):
The MSDN page on SqlConnection.Close says that:
The Close method rolls back any pending transactions. It then releases the connection to the connection pool, or closes the connection if connection pooling is disabled.
Also, in the SqlConnection page it is stated that:
If the SqlConnection goes out of scope, it won't be closed. Therefore, you must explicitly close the connection by calling Close or Dispose. Close and Dispose are functionally equivalent. If the connection pooling value Pooling is set to true or yes, the underlying connection is returned back to the connection pool. On the other hand, if Pooling is set to false or no, the underlying connection to the server is actually closed.
and:
To ensure that connections are always closed, open the connection inside of a using block, as shown in the following code fragment. Doing so ensures that the connection is automatically closed when the code exits the block.
This should answer your questions.
EDIT:
For further readings (also seen in your comments) you can read about Connection-Pooling and of course check out the source code for SqlConnection.
Sql Connection object in an object which we create using Sql connection class which belongs to System.Data.SqlClient namespace. We use Sql Connection object to execute sql commands in sql server database.
Close and Dispose are two different things. You can reuse the connection if you close it but not after dispose it.
It is always a good practice to open the connection just before you want it and close it once done your needs.
In c#, the connection will be disposed if you create the connection with “using” statement.
Related
Everytime you use spring JdbcTemplate, does it actually create a new connection to the sql server ?
Answer 1:
In short yes it does close the connection. The long answer it depends.
When you don’t have a Spring managed transaction then yes the JdbcTemplate will call the close() method on the Connection. However if there was already a connection available due to Springs transaction management closing the connection will be handled by Springs transaction support, which in turn also will call close() on the Connection.
The only difference is when the connection is closed but close() will be called.
If the connection will be actually closed depends on which DataSource is used, in general when using a connection pool the connection will be returned to the pool instead of actually closing the connection.
Answer 2:
Yes it does.
And if the connection was obtained from connection pool, it won’t actually close the connection, rather will send it back to the pool.
Answer 3:
No need to close the connection manually. Spring container itself to take of the operation. Kindly refer this spring url,
http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html
Answer 4:
We can also close connection while using jdbcTemplete, in some cases it compulsory to close connection after execute query otherwise getting connection issue. for more details visit
[Close connection in jdbc template][1] [1]: http://www.javaiq.in/2019/05/jdbctemplate.html
Link is: https://inneka.com/programming/spring/does-springs-jdbctemplate-close-the-connection-after-query-timeout/
Understanding datasource interface is the key to understanding the answer to this question. JdbcTemplate has a dependency on datasource and official javadoc for DataSource interface says:
Datasource is a factory for connections to the physical data source that this datasource object represents.
It means every-time a JdbcTemplate is used for executing a SQL query, it requests a connection from the datasource. Datasource retrieves a connection from the connection pool, if available, and gives it to JdbcTemplate. JdbcTemplate then executes the SQL query and releases the connection back to the pool.
So, yes, we would need a new connection every-time JdbcTemplate is used for executing a SQL query but that connection is always fetched from the connection pool that any implementation of Datasource interface maintains.
Maintaining a connection pool is lot more time efficient than creating a new connection on demand. Obviously, considering memory limits, there has to be an upper cap on the connection pool size.
I am a DBA, not a developer, and could use some insight. The development staff is using VB.NET to create web based applications with connections to a DB2 database. Please assume that the connection string in the web.config file is coded correctly.
I can see the number of orphaned connections from the web servers grow over time. By orphaned I mean that there is no activity associated with the connection for hours, yet I can see other connections being created and destroyed every couple of seconds.
I suspect that the connections are not being properly closed, but there are two different groups looking at the problem and so far haven't turned up anything. By the end of the day I can have hundreds of these connections - all of which are cleared when the application pool is reset every night. (This means it is NOT a database problem)
Is there a coding technique to ensure a connection is closed using vb.net on IIS v7+?
Am I seeing the symptom of another problem on IIS?
You need to have the developers implement the Dispose pattern, which is facilitated by the Using statement in VB.NET, like this (this is pertinent to SQL Server, but whatever connection object you are using for DB2 should work as well):
Using theConnection As New SqlConnection()
'' Command, parameter logic goes here
End Using
By wrapping the connection object inside of a Using block, it will guarantee that the connection is closed and properly disposed of memory-wise, even if there is an exception in the code within the Using block.
Sounds like a code-review is in order for whoever is in charge of the developers.
I am considering using Fluent NHibernate for a new application with SQL Server 2008 and I am having trouble understanding the connection handling behavior I am seeing.
I am monitoring connections using sp_who2 and here is what I see:
When the SessionFactory is created, a single connection is opened. This connection
seems to stay open until the app is killed.
No connection is opened when a new session is opened. (That's ok, I understand NHibernate waits until the last moment to create database connections).
No new connection is opened even when I run a query through NHibernate. I must assume it is using the connection created when the SessionFactory was created, which is still open. I set a breakpoint after the query (before the session was closed), and no new sessions had appeared in sp_who.
Running an entire app through a single connection is not acceptable (obviously). How can I ensure each ISession gets its own connection? I'm sure there's something obvious I'm missing here...
Thanks in advance.
The behaviour that you see is nothing NHibernate specific - Connection pooling is default behaviour in SQL Server.
Even if it may sound awkward at first glance, it actually is a good thing because creating new connections and maintaining them is expensive.
(for more information, see the Wikipedia article about connection pooling)
So there is no need to try to get NH to open a new connection for each session, because reusing existing connections actually improves SQL Server performance.
I have to work with a Project made by another developer. A project Win-Form with Visual-Basic code, with MS-Access as db and some OleDbConnections. There is a bug: sometimes the application can't open the OleDbConnection because the max number of connections has been reached on the db. I know the best way to use the connections is this:
Using cn As New OleDbConnction(s)
...
cn.Close()
End Using
But in the project there are many classes to work with the db, and in many of these classes there are OleDbConnections with "Friend" visibility, that are opened and closed in different times. For this reason it's impossible to put all the OleDbConnections in a Using construct, and it's very very hard to find what operation "forgets" to close one of these OleDbConnection.
A possible solution could be to use only one unique public OleDbConnection, and to check, before opening it, if it isn't already opened.
But someone have told me it's a very bad practice. I suppose he told me this about the performance, but I don't know it exactly.
Can you tell me why one unique public OleDbConnection is so deprecated?
Have you got, for me, an "easy" solution for my problem?
Thank you,
Pileggi
From your description, I see a couple of possible issues that could result in your problem:
nested connections:
You open multiple connections within each-other
open/release connections too fast:
As David-W-Fenton mentionned, with access, every time you open/close a single connection, the lock file will be created/removed. This operation is quite slow and if you quickly open/close the database within you application (execute lots of atomic queries), you may get this issue.
A few possible ways to investigate and solve the issue:
Trace all open/close calls
Add some debug traces that show every time you open and close a connection.
It will allow you to detect nested connections and where your connection pool is being wasted.
Force connection polling
An easy 'fix' may be to explicitely set connection pooling in your connection string. It should be the default behaviour, so maybe it won't do anything to solve your problem, but it's so simple that there is no reason not to try it:
OLE DB Services=-1
Use a connection manager class to create/release connections for you.
Replace all the explicit creations of new OleDbConnection and close operations by your own code.
This would allow you to always re-use a single existing connection throughout your application and allow you to quickly make tweaks for the whole of your app by centralising the behaviour in a single place.
So why holding a single connection is generally deprecated?
Generally, you should not keep connections open throughout your application as they force the database server to keep resources available for you, and it decreases the number of client that can connect (there is always a limited number of connections available).
For Access though -a file-based database without server part- keeping a single connection open is actually preferable because of the delay associated with opening new connections (creation of the lock file). Since Access is not meant to be used with a large number of concurrent users, the resource cost of keeping the connection open is not significant enough to be an issue.
From simple tests, it can be shown that keeping a connection always open allows subsequent connections to open about 10x faster!
The OleDb driver does connection pooling for you, so it is able to re-use connections when they are freed.
By keeping your connections and database operations small and contained, you would be less likely to run into concurrency issues when using threads. Keeping a global connection may become an issue if you are executing multiple operations using the same pipeline to the database.
Just adding some information that works for years successfully for me (it is somewhat similar to what David-W-Fenton suggests)
First, an OleDbConnection to Microsoft Access (MDB, JET) is not using connection pooling. As Microsoft states in KB191572:
Connections that use the Jet OLE DB providers and ODBC drivers are not
pooled because those providers and drivers do not support pooling.
Regarding connection pooling, there is also this blog post from Ivan Mitev that states:
So what does this mean? It is apparent that that the presence of an
actively opened connection made the test with multiple connection
closing and opening finish a lot faster (2-3 times). The only possible
explanation for me is that the connection pool is released each time
there are no active connections. I have to make further investigations
and read something like Pooling in the Microsoft Data Access
Components. Or maybe hold a single opened connection just for the sake
of keeping the pool alive. This would be ugly, but still it is a good
enough workaround! If anyone has a better idea, please share it.
And Microsoft notes in MSDN:
The ADO Connection object implicitly uses IDataInitialize. However,
this means your application needs to keep at least one instance of a
Connection object instantiated for each unique user—at all times.
Otherwise, the pool will be destroyed when the last Connection object
for that string is closed.
Based on all this and my own tests, my solution to "simulate" connection pooling even with Microsoft Access databases roughly follows these steps:
Open one OleDbConnection to the Access database as early as possible in application lifecycle.
Do your normal SQL queries, disposing OleDbConnections as early as possible, just like recommended.
Dispose that one always-open OleDbConnection as late as possible in application lifecycle.
This sped up my applications (mostly WinForms) tremendously.
Please note that this also works for Sqlite which seems to not support connection pooling, too.
I have a test console app that is executing sql scripts to create a database and its tables, then inserting data. I use DAO to create, retrieve, update, and delete from the tables and then try and drop the database, but it can't because it says it is currently in use. How do I kill the connection? Through debugging and running a sql script to see the total connections, I've narrowed it down to this piece of code that is not killing the connection. Even though it says the connections are cleared, the database says it is still connected.
foreach (ISessionFactory factory in this.connections.Values)
{
factory.Close();
}
this.connections.Clear();
this.connections = null;
NHibernate manages all the database connections itself. It opens and closes the database as it sees fit, but you can try to call Session.Disconnect to get it to disconnect from the ADO.NET connection.
However ... if you have Connection Pooling enabled, which is normally the 'default' connection behavior, the connection will only be returned to the connection pool, not released, and it will still show as a connection, so you would have to clear the connection pool.
Unfortunately, I do not know if you can do this directly thru NHibernate, but you can use a SQLConnection object to issue a ClearPool or ClearAllPools call ...