Synchronous Methods using Asynchronous Connection  
Author Message
Lyam1971





PostPosted: .NET Framework Data Access and Storage, Synchronous Methods using Asynchronous Connection Top

From the following MSDN article ( http://www.hide-link.com/ ) it states:

"then you can still use the synchronous methods in connections opened with async=true, and they'll behave as usual; you'll see a small performance degradation, though."

How much is a small performance degradation 1-2%, 10%, 20%, more Is the overhead and complexity of maintaining 2 seperate connection types in my application truly offset by the "small performance degradation"

Also, how does maintaining 2 types of connections work with connection pooling Are there 2 separate connection pools maintained in the background and how does the system know which pool to draw from when I request a new connection Or do I have to maintain my own connection pools and not use the built-in connection pooling of the SQLClient

Any feedback would be welcome. Thanks!

Mike



.NET Development14  
 
 
CommonGenius.com





PostPosted: .NET Framework Data Access and Storage, Synchronous Methods using Asynchronous Connection Top

There is only one connection pool. When you open a connection, the system checks if there is an unused connection which matches the requested configuration in the pool. If so, it uses it; if not, it creates a new one.

 
 
Sarah Parra - MSFT





PostPosted: .NET Framework Data Access and Storage, Synchronous Methods using Asynchronous Connection Top

Conceptually, I usually think of a connection pool as a group of like connections, meaning they share the same connection string, user context, and transaction scope. In that sense, this scenario would create two pools, one for each different connection string. However, the internal details and what constitutes a "pool" is really not significant here. You don't need to do anything yourself, except using one connection string with async=true and the other with async=false (the default).

In this scenario, the overhead of using two different connection pools (using my definition above) is definitely less than making synchronous calls over an asynchronous-enabled connection. There is very little memory overhead to having a separate pool, and the cost of pulling connections from/putting connections into the pool isn't really increased just because you have two pools instead of one.

The only time I have really seen multiple pools be an issue is if you are doing something that is causing there to be only 1 or 2 connections in each pool for some reason. For example, you have lots of different connection strings all over the code, or you are using integrated security at both the IIS and SQL levels, which means that users cannot reuse each others' connections. In that scenario, the problem is really not even the number of pools per se, but it's the fact that you're getting little to no reuse of connections, which is the whole point of using pooling in the first place.

I hope this helps!

Thanks,
Sarah

Please Mark as Answer if this answers your question, or Unmark as Answer if it is marked and you feel it is not answered.