I'm reading connection pool from MSDN.
I face with this sentence:
If a connection exists to a server that has disappeared, this
connection can be drawn from the pool even if the connection pooler
has not detected the severed connection and marked it as invalid. This
is the case because the overhead of checking that the connection is
still valid would eliminate the benefits of having a pooler by causing
another round trip to the server to occur. When this occurs, the first
attempt to use the connection will detect that the connection has been
severed, and an exception is thrown.
Can everybody explain disappeared connection?And why a connection will be disappeared ?
It's not the connection which disappears. A pooled connection is an established network connection. Now until data is sent over the connection, a problem with the connectivity to the server (e.g. network issue) may not be detected.
Therefore, the following can happen:
Connections are open to a SQL Server, and get added to the pool
The network link gets broken (in a way which is not immediately detected, such as a router problem; an unplugged cable on the client would likely be detected right away)
Shortly after an application draws a pooled connection from the pool
The connection is returned as if the server was reachable, because no check is done to verify this (which is what the quoted information is about)
On first use an exception will be thrown
Related
I have a software operating via WLAN mounted on a moving device.
At the moment transactions are opened and closed in code. Between the businesslogic is happening.
Now i'm suffering of lost connection and staying open transactions on the database. (MSSQL 2012)
My solution was to move all transactions/logic to a sp.
So the client only calls the sp and transations are handled inside.
My question here is:
What happens to a sp wenn the connection is lost? Does it run to the end?
This is covered in the documentation Controlling Transactions (Database Engine), specifically in the Errors During Transaction Processing section:
If an error prevents the successful completion of a transaction, SQL
Server automatically rolls back the transaction and frees all
resources held by the transaction. If the client's network connection
to an instance of the Database Engine is broken, any outstanding
transactions for the connection are rolled back when the network
notifies the instance of the break. If the client application fails or
if the client computer goes down or is restarted, this also breaks the
connection, and the instance of the Database Engine rolls back any
outstanding connections when the network notifies it of the break. If
the client logs off the application, any outstanding transactions are
rolled back.
I've emphasised the relevant section.
So, moving the transactions to the SP won't stop the transaction being rolled back if your connection drops. I would suggest finding out why your connection is unstable and fixing that. Otherwise you'll need to work out a way to run the query locally on the instance (perhaps, using SQL Agent).
I have some doubts related to connection pooling. In SQL Server Connection Pooling article it was mentioned like " When a new connection is opened, if the connection string is not an exact match to an existing pool, a new pool is created. Connections are pooled per process, per application domain, per connection string and when integrated security is used, per Windows identity."
Now i have my own windows form application which has SQL connection.
So when I open application the SQL connection open for first time and a pool is created. So if i close the application does pool gets destroyed automatically or will it be exists even after application is closed?
If I open the application again after some time does the connection drawn from the existing pool if already exists or not?(but it is mentioned like pool is per process)
There exists connection timeout for a connection. So is there any timeout for a pool too?
Connection pools are in the end nothing magical. Think of them as .NET objects that simply keep a list of connections.
As such these objects exist per AppDomain and live inside the CLR, which is bound to the lifetime of your process.
If your process goes away, so does the CLR instance, so do the AppDomains and so do the connection pools. Just like any other .NET object you had.
If you restart your application the connection pools get recreated, again based on the rules described by MSDN.
1) as you quoted the pool is pooled per process, so if you close your application it closes the pool.
2) Does not matter as the pool is per process, when you close the application it closes the pool.
3) Yes, it is set in the connection string with the key Connection Lifetime or Load Balance Timeout.
Connection Lifetime
-or- Load Balance Timeout
When a connection is returned to the pool, its creation time is
compared with the current time, and the connection is destroyed if
that time span (in seconds) exceeds the value specified by Connection
Lifetime. This is useful in clustered configurations to force load
balancing between a running server and a server just brought online. A
value of zero (0) causes pooled connections to have the maximum
connection timeout.
If you do not use the above setting (it defaults to 0) it will just use the default behavior of the pool
The connection pooler removes a connection from the pool after it has been idle for approximately 4-8 minutes, or if the pooler detects that the connection with the server has been severed.
The connection pooler removes a connection from the pool after it has been idle for approximately 4-8 minutes, or if the pooler detects that the connection with the server has been severed. Note that a severed connection can be detected only after attempting to communicate with the server. If a connection is found that is no longer connected to the server, it is marked as invalid. Invalid connections are removed from the connection pool only when they are closed or reclaimed.
If a connection exists to a server that has disappeared, this connection can be drawn from the pool even if the connection pooler has not detected the severed connection and marked it as invalid. This is the case because the overhead of checking that the connection is still valid would eliminate the benefits of having a pooler by causing another round trip to the server to occur. When this occurs, the first attempt to use the connection will detect that the connection has been severed, and an exception is thrown
refer this link Connection Pooling remove connections section
Pools are destroyed if there is no activity for a specified amount of time. More details on inactivity time can be found here. I believe this will answer #3 as well. However, if you specify the MinPoolSize in the connection string, it is destroyed when AppDomain is unloaded and process ends.
A pool is specific to process so each time a pool will be created.
I am working on multi threaded application(a server) where I used to handle 2000 clients at a time and I am opening separate database connection of MySQL database in each thread. So I have enabled the connection pooling. I searched on many blocks that after using connections we should close it then it will return back to pool and will be used by other thread.
on the other hand we know that connection making is a time consuming process. So my question is why should we close connection in connection pooling. and what is better keep connection open or close them?
we know that connection making is a time consuming process
Correct - that's why we have connection pools. They maintain connections, so you don't create new ones.
why should we close connection in connection pooling
So they are returned to the pool to be used by other threads.
Connections are expensive resources, so you want to open, use and close them as quickly as possible, so they will return to the pool and be available to other threads.
When you 'Close' a connection that is pooled;You are saying that you are done with the connection and the pool can use it again.
Calling Close does not physically tear down the connection. The pool has its own logic to determine when connections are physically closed.
I have a project that connects to a RMS file system through Attunity (Version 1.0.0.8). The RMS file is in a different server. The connection pool on both client and service is 10 (Max connection pool size). When we hit the server from the client, we sometimes get the error:
C014: Client connection limit reached - try later.
I would like to understand whether this error is related to Server overloaded or any issues on the Client side. I am sure that the client code that I am using to connect to the server is properly opening and disposing the connection.
This sounds like a problem we were having. We were running Attunity on OpenVms and we were maxing out the number of DECNET connections to Attunity between our nodes; the underlying problem was with our client. The clients in this case would induce a longstanding transaction or had problems releasing their connections back to the pool. We fixed the issue by eliminating the longstanding transactions and then finding the bug in the clients where the they would not release their connection. Unfortunately, all of our clients are implemented in Java and Cobol, so I don't have any .Net specific advice.
I don't know what kind of error is this.. I can't open my site anymore
Server Error in '/site' Application.
Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
please help me.. tnx
10 Tips for Writing High-Performance Web Applications
Connection Pooling
Setting up the TCP connection between your Web application and SQL Server™ can be an expensive operation. Developers at Microsoft have been able to take advantage of connection pooling for some time now, allowing them to reuse connections to the database.
Always close your connections when you're finished with them. Do not trust the common language runtime (CLR) to clean up and close your connection for you at a predetermined time. The CLR will eventually destroy the class and force the connection closed, but you have no guarantee when the garbage collection on the object will actually happen.
To use connection pooling optimally, there are a couple of rules to live by. First, open the connection, do the work, and then close the connection. It's okay to open and close the connection multiple times on each request if you have to (optimally you apply Tip 1) rather than keeping the connection open and passing it around through different methods. Second, use the same connection string (and the same thread identity if you're using integrated authentication). If you don't use the same connection string, for example customizing the connection string based on the logged-in user, you won't get the same optimization value provided by connection pooling. And if you use integrated authentication while impersonating a large set of users, your pooling will also be much less effective. The .NET CLR data performance counters can be very useful when attempting to track down any performance issues that are related to connection pooling.
Whenever your application is connecting to a resource, such as a database, running in another process, you should optimize by focusing on the time spent connecting to the resource, the time spent sending or retrieving data, and the number of round-trips. Optimizing any kind of process hop in your application is the first place to start to achieve better performance.
A timeout expired (something took longer than it should). Specifically, the timeout period elapsed prior to obtaining a connection from the connection pool. It turns out This may have occurred because all pooled connections were in use and max pool size was reached.
(You're using Connection Pooling and probably not closing your connections. After you are done with a SqlConnection or similar connection object, call .Close() on it)