无状态WCF服务和数据库连接池

Question

The question has been asked before here in StackOverflow, but in my experience, the answers were actually wrong. At least for .NET Framework 4.0 and SQL Server 2005 they are wrong.

I would need help to sort this out once and for all.

The question is - can a stateless WCF service use database connection pooling in some way?

See Can a Stateless WCF service ...

The earlier answers essentially stated that there is no problem and no difference to any other ADO.NET scenarios. However, I have not been able to get a stateless WCF service to use the connection pooling EVER, while I can see it always work outside WCF services. No matter what connection strings or parameters I am trying to use, it does not do it.

Database connection pooling is meant to be enabled by default, so a simple connection string should get me there, for instance on SQL Server Express:

SqlConnection sqlCn = new SqlConnection("Data Source=SERVER\SQLEXPRESS; Initial Catalog = xDB; Integrated Security = SSPI;")

Using this connection, in a Windows Form application, if I do 3 consecutive rounds of sqlCn.Open() -- query the database -- sqlCn.Close() , I am getting a long delay (for instance 2 seconds) on the first sqlCn.Open() , and no delays at all on queries and open / close afterwards. Exactly what I expect with database connection pooling.

But if I make 3 calls to a WCF service containing the same sqlCn.Open() -- query the database -- sqlCn.Close() code, I am getting the 2 second initial slow startup for EVERY single call.

My guess is that the connection pooling is entirely controlled by the ADO.NET objects created by my code, and since I am instantiating any ADO.NET classes I use (such as SqlConnection etc) inside my WCF service, they get destroyed when my service call is over and the connection pool along with it.

This may not be true, but if not, is there anything wrong with what I have done?

Anyone have any experience with that?

(Please do test any assumption or theory before posting)

Answer 1

1) Here's the documentation:

http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx

When a connection is first opened, a connection pool is created based on an exact matching algorithm that associates the pool with the connection string in the connection. Each connection pool is associated with a distinct connection string. 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. Connection strings must also be an exact match; keywords supplied in a different order for the same connection will be pooled separately.

2) Per the same link, "By default, connection pooling is enabled in ADO.NET."

3) This is completely independent of whether the WCF call in question is stateless or not.

4) Finally:

We strongly recommend that you always close the connection when you are finished using it so that the connection will be returned to the pool. You can do this using either the Close or Dispose methods of the Connection object, or by opening all connections inside a using statement in C#, or a Using statement in Visual Basic. Connections that are not explicitly closed might not be added or returned to the pool.

Answer 2

I managed to resolve it myself.

I had to explicitly state "Pooling = true" (and add a non-zero "Min Pool Size") to my connection string. Then it was working consistently. If this was not set, it would sometimes factually work as expected, but mostly not.

I tested it also with different user accounts (SQL Server authentication with user name / password versus "Integrated Security = SSPI"). Both approaches work for a WCF service as long as you set "Pooling = true".

No data if this is a problem only for my installation / SQL Server version / ADO.NET version but it sure did take quite a while to resolve.