I've a C# client application that need to checks a table on a Postgres db every 15 minutes. The problem is that I need to install this client into more or less 200 client so, for that I need to close the DB connection after the query.
I use .Close() method but, if I check on pg_stat_activity table on Postgres DB, I can see the connection still open in IDLE status. How can I fix that issue? Is it possible to close definitely the connection?
thanks,
Andrea
Like most ADO.NET providers, Npgsql uses connection pooling by default. When you Close() the NpgsqlConnection object, an internal object representing the actual underlying connection that Npgsql uses goes into a pool to be re-used, saving the overhead of creating another unnecessarily. (See What does "opening a connection" actually mean? for more).
This suits most applications well, as it's common to want to use a connection several times in the space of a second.
It doesn't suit you at all, but if you include the option Pooling=false in your connection string, it will override this default, and Close() will indeed close the actual connection.
Related
Actually I am confuse about one thing.
I have .net application and using sql server 2008 for database.
Now, on my Method A i am filling datareader.
now, during while loop i am calling another method B by pass one property of result.
at that time i also open DB connection & close it.
same thing doing Calling another method C from method B.
at that time also open DB connection & close.
To fill final list of Method A. it is taking time.
so, my point is.To open DB connection & closing it. Is it time consuming process?
To open DB connection & closing it. it is time consuming process
Yes. If pooling is enabled and the connection is returned from the pool then opening and closing costs at least one round-trip, to reset the connection. If the connection is not pooled opening and closing is a full SSPI complete handshake. If SQL authentication is used and encryption is enabled, there is another complete SSL handshake to establish a secure channel before the SQL handshake. Even under ideal conditions, it takes 10s of ms, it can go up to whole seconds with some minimal network latency added.
A well written ASP.Net application needs one (pooled) connection per request, never more.
It is generally very bad practice to connect to a third part application (database, WebService or similar) in any kind of loop. Communication like this is always takes a relatively long time.
As the number of elements in the loop increases the application will become exponentially slower and slower.
A much better approach is to perform an operation for all the elements then pass the required data into your loop logic.
As with all things there are exceptions, loops where you have millions of entities to process and the connection is a small overhead may create circumstances where it's more efficient to process each entity atomically.
I currently have a working program that is monitoring a few SQL tables and transferring data to MySQL tables. Essentially, I have a loop that checks every 30 seconds. My main concern is that I currently need to close and open the connection every time I loop. The reason for this is because I was getting errors about multiple transactions. When I close my connections, I also need to dispose the connection. I thought that disposing the transactions would have solved this problem, but I was still getting errors about multiple transactions.
This all seems to be working fine but I was wondering if there was a better way to do this without closing the connection.
I am not sure about your errors but it seems that you have to increase the number of connections to the remote computer. Have a look here http://msdn.microsoft.com/en-us/library/system.net.configuration.connectionmanagementelement.maxconnection.aspx
Also you can try to do is use only one connection to realize multiple SQLs.
If it is doesn't help then please provide your code to check it...
Were you committing your transactions in your loop? transaction.Commit() ... that could have been the issue... Hard to say with no code. No need to worry about opening and closing connections anyways since ADO.NET uses connection pooling behind the scenes. You only actually 'open' a connection the first time, after that is kept open in the pool to be used again. As others have said though, Post some code!
is it be better to open connection to database -
make any querys...update....delete -
and after i use to close this connection
or
open the connection when the program load -
and close when the program close ?
thanks in advance
In general, you Close (Dispose) as soon as possible in your code. With a try/finally or using block.
What actually happens depends on the ConnectionPool settings for your app.
Basically the presence of the ConnectionPool means you don't have to worry about the using of connections (how many, how long to maintain) anymore, it becomes an external configuration.
BTW: With the exception of the WinCE framework, slightly different rules there.
always close the ADO.NET connection when you finish with it. The reason is that connection are pooled behind by the ado.NET infrastructure, so even if open a connection the first time takes a while, by closing it you release to the pool so other part of the application can have a connection faster. Some exeption to this rule can be done with some embedded database, but we need to look at the single case.
You should always close your connections immediately using using blocks.
Closing a connection is not the same as Disposing. A closed connection can be re-used by the connection pool based on a dictionary look-up on the connection string(your connection string must be identical to make use of pooling, but this feature is transparent). On the other hand, if you dispose or use USING, then the connection object will be destroyed and cannot be re-used.
If you plan on re-opening the connection a short time later, it would be more performant to use Close.
For some reason it takes 7 seconds to open a connection to a sql server database for the firt time, subsequent connections takes a second. any idea what could be the reason?
I'm using C# and asp.net
Its after compilation, i essence every time i restart the site, which means every time it needs to actualy create the "first" connection. i understand that setting up connection pooling has overhead, but i have never seen that i should take 7 second to set it up.
As well as connection pooling and CLR compilation, don't forget that the data and plan caches on the database server could be "cold" too...
I've seen first calls on a very "cold" web site take 5-10 seconds to respond from button click (for example, "search") to the data ending up on screen.
The first time the connection has to be established which has a lot of overhead. Each subsequent connection is using connection pooling (assuming you have the same connection string) and the initial setup does not need to be done.
Edit: see this link or this one for some info on connection pooling.
is this after a compile each time? Is the "lagtime" due to JIT compiling rather than the SqlConnection itself?
I'm writing a server application that's communication with a local sql server.
Each client will need to read or write data to the database.
Would it be better to have a thread safe class which will enqueue and executes the sql commands on a single sql connection? Or should I open a new connection for each command? Does it matter much for performance?
If you have a batch of statements that have to be executed after each other, you should use the same SqlConnection.
As soon as you do not longer need the SqlConnection, and you do not know when you will need a connection again, you should close the connection.
So, if you have to execute 2 insert statements and one update statement after each other, for instance, you should use the same SqlConnection.
The most important advantage here, is that you can put those statement in a transaction if necessary. Transactions cannot be shared accross connections.
When you're finished working with the DB, you can close the connection. By default, connection pooling is used, and the connection will be returned to the pool, so that it can be reused the next time you need a connection to the DB.
Connection lifetime should be short, but you should not use a separate connection for each DbCommand.
If you are using any flavor of ADO.NET, connection pooling will automatically be used (at least with SQL Server) unless you explicitly disable it, so there's no reason to do anything special about that.
Be sure to remember to Close your connections after each used - this will simply return the connection to the connection pool.
Usually you should create a new connection for each command and take advantage of the in-built connection pooling.