Just got home... ;-) The OleDb data provider and the Odbc data provider use the resource dispenser architecture, popularized by MTS, but also available outside of MTS/COM+/EnterpriseServices. In any OLE DB provider or ODBC driver, pooling works the same way. The only configurable parameter, on a driver-by-driver or provider-by-provider basis is the stale connection timeout, although ODBC has a single retry wait time. The resource dispenser architecture is doc'd in the platform SDK docs, as is the mechanism used by the OLE DB service components.
In OLE DB, pooling works via the OLE DB service component architecture (that's the resource dispenser); in ODBC the driver manager is the RD. OLE DB providers must support COM aggregation to be poolable, almost all do. Pooling is based on connection property name-value pair matching in OLE DB, in ODBC I believe they do string compare of the connection string. Pooling also takes into account (in SqlClient, OleDb or Odbc) integrated security principals (must be the same if integrated security is specified) and connections enlisted in Enterprise Services transactions (they can't be reused except in the same transaction). Hope this helps, Bob Beauchemin [EMAIL PROTECTED] -----Original Message----- From: Shawn Wildermuth [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 7:20 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] connection pooling strategy For the OleDb Managed Provider, the pool depends on the particular OLEDB Provider. I am sure Bob B. will chime in on this one. He's knows this stuff cold...I don't: ) For the SqlClient Managed Provider, the pool indeed depends on indentical connection strings. The scope of the pool is per connection string and per process. A couple caveats if you start looking at this: - Connection Pooling is specificly disabled under the debugger (dunno why, but MS confirmed this behavior) - If you are using NT Authentication and Integrated Security, your connections unlikely be pooled since the complete connection string will be different for every NT identity. HTH, Shawn Wildermuth [EMAIL PROTECTED] > -----Original Message----- > From: dotnet discussion [mailto:[EMAIL PROTECTED]] > On Behalf Of Anye M. Sellers > Sent: Friday, May 03, 2002 9:23 PM > To: [EMAIL PROTECTED] > Subject: [DOTNET] connection pooling strategy > > > Hi folks, > I'm trying to come up with a scalable connection > pooling strategy. I know that .NET has connection > pooling built in to the SqlConnection and > OleDBConnection objects, but I'm not sure exactly how > it works. The documentation says if the same > connection string is used, the same pool is used; but > I am unclear on what the scope of this is. In other > words, if I use the same connection string throughout > my entire application, is it using one pool, or do I > have to be using the same connection string within a > class or within a namespace? It seems like if it is > only within a class (or a particular instance of a > class) we would end up with a whole lot of pools. > When I used to work with Java App Servers, the > connection pool was managed on an application-wide > basis, but of course I don't know if .NET is the same. > > For enterprise applications is there an advantage to > having multiple pools (i.e. one used by each module) > as opposed to one pool shared within an entire > application? > > Thanks in advance... I'm still learning the > architecture side of the fence. > > Anye > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - your guide to health and wellness http://health.yahoo.com You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
