I've been thinking about connection pooling with the SQL Server managed provider, and have a few thoughts/questions:
1. ADO.NET connection pooling is tied to a specific process. Thus, if you want to share a connection over multiple clients, you need to host your database component in an ASP.NET application or through .NET Remoting (and pay the price of the extra network call), right? 2. What technology underlies connection pooling in the SQL Server provider? I've read that it is COM+, but this seems unlikely. 3. Database connections seem to be the key scalability bottleneck in an enterprise application. With the use of connection pooling, isn't a 80% of the reason for using COM+ services like object pooling and JIT activation avoided? In other words, can you think of an example of a serviced component that encapsulates an expensive resource (and so should be pooled) that isn't related to a database? 4. In a distributed application, it saves a few headaches to let the clients communicate with a Remoting layer, which then uses COM+ serviced components on the same machine. This bypasses the DCOM problems that occur with remote serviced components. But does this reduce the efficacy of COM+ in any way? Any thoughts or experiences welcome. .NET certainly is a fascinating technology shift.... Matthew You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
