A few answers: 1. ADO.NET connection pooling is per-appdomain rather than per-process. This especially matters in ASP.NET, in which each application is a separate appdomain. You can call a remote process that uses a connection, but can't pass Connections themself around.
2. SqlClient connection pooling is implemented using similar code (conceptually) to COM+ pooled objects, but this code does not use COM+ pooled objects under the covers. It lives in System.Data.SqlClient. There is some information about this in the docs, or, this being .NET, you can read the code. 3. The one that comes to mind is shared memory, which had been used effectively as a pooled object and is not a database. 4. It restricts the security implementation possiblities, for one thing. Hope this helps, Bob Beauchemin [EMAIL PROTECTED] -----Original Message----- From: Matthew [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 6:53 AM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] ADO.NET and Connection Pooling 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. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
