This property controls the maximum age of connections, in seconds. It controls whether the connection will automatically be reset (clearing any pending results) when it's returned from the pool. This property can be true (the default) or false.
It controls whether a connection will automatically enlist in the calling thread's transaction when it is taken from the pool. This one can be true (the default) or false. This property is an integer with a default of 100 and specifies the maximum number of connections to maintain in the pool. If you set this to 5, for example, the first time you connect to the server, ADO.NET will create five connections and prepare them for pooling. It specifies a minimum number of connections to maintain in the pool. This property is an integer with a default of zero.
This property is helpful if you know that you'll never have an identical connection request in your application and would like to avoid the overhead associated with managing the pool. Use this property to specify that a particular connection should not participate in the pool, but instead should be destroyed when it is closed. There are six pool-related connection string properties. You'll want to use identical values in all connection strings in your application to be sure the connections can be pooled. Another is to authenticate users to your application, but then use an application role to connect to the SQL Server.ĪDO.NET allows you to control the connection pool by adding values to the connection string.
#Sql server connection string pooling password#
One possibility is to use integrated security rather than user name and password security on your SQL Server. In this situation, consider whether you can avoid placing authentication information directly in the connection string. In this case, the second request will not be satisfied by returning the first connection from the pool, because the second connection string is not identical to the first one. You use that connection, close it, and then initialize a SqlConnection object with this ConnectionString property:Ĭnn.ConnectionString = "Server=MAINSQL Initial Catalog=DB1 username=Mary password=pw2" Suppose you initialize a SqlConnection object with this ConnectionString property:Ĭnn.ConnectionString = "Server=MAINSQL Initial Catalog=DB1 username=John password=pw1" If you're using connection strings with user information, the corresponding SqlConnection objects won't pool with each other.
Instead, it returns them to the connection pool. To minimize this delay, ADO.NET doesn't throw SqlConnection objects away when the Close or Dispose methods are called. When ADO.NET opens a SqlConnection object, this delays the application. Making a SQL Server connection is fairly costly. To get past this bottleneck, I tuned the connection pool that the application used to retrieve data from SQL Server.Ī connection pool is a set of SQL Server connections maintained by ADO.NET and is used to communicate with SQL Server. After a few hundred users, the application hit the wall and performance dropped, despite plenty of network bandwidth and server processing power. I recently looked at an ASP.NET application where performance was acceptable up to a certain point, but then decreased rapidly.
0 kommentar(er)
