Wednesday, July 25, 2007 11:45 AM
kolbis
This is how I wish Connection Pools would behave...
What are Connection pools should be by now a common knowledge. If by any case you still need a definition, read the following lines, otherwise jump to the next paragraph. Opening a database connection is a resource intensive and time consuming operation. Connection pooling increases the performance of Web applications by reusing active database connections instead of creating a new connection with every request. Connection pool manager maintains a pool of open database connections. When a new connection requests come in, the pool manager checks if the pool contains any unused connections and returns one if available. If all connections currently in the pool are busy and the maximum pool size has not been reached, the new connection is created and added to the pool. When the pool reaches its maximum size all new connection requests are being queued up until a connection in the pool becomes available or the connection attempt times out.
So, connection pools in ADO.NET is created per connection string. So far so good, but lets say that you have two applications that uses the same connection string to the same provider (e.g. MSSQL). What is going on then? Will the two application share the same connection pool?
The answer to this is NO!
According to Microsoft:
“Connections are pooled per process, per application domain, per connection string and when using integrated security, per Windows identity.”…
This is surely bad news, because I wished that I could share the pool between two applications per provider and by doing so utilize my connection resources in a better way. Now I will have to implement a service layer that will behave the way I wished it would to begin with :(
תגים:.NET, SQL Server, Connection Pools