> 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?
Yes. This is, in fact, one of the primary motivations for using a three-tier architecture (as opposed to directly connecting clients to a database). > > 2. What technology underlies connection pooling in the SQL > Server provider? I've read that it is COM+, but this seems unlikely. I believe they've rolled their own. > 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? Well, that's the big one, but anything that has a large one-time setup but small per-context activation cost would be eligible. Think about other types of non-DB connections, like say a connection to a big piece of automation machinery or a connection to a mainframe. Some of these can take many seconds to set up. > 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? I personally don't see any problems with it, but I tend to design my COM+ components in the Ewald style, so they're stateless/SingleCall, which makes them a lot easier to use in this scenario. The one thing I can see it making harder is role-based security. IIRC, security info isn't propagated with Remoting the way it is with DCOM. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
