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.
|