Is connection pooling on a per process-per conn string basis?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

The subject says it all; I have a windows app that connects to a db. If I
run two instances of the same exe in the same machine, then two connection
pools are created in the database server despite the fact that they use
exactly the same connection strings. MSDN docu doesn't mention this at all,
hence my request for confirmation. If that is indeed the case, then I guess
it's not a very scalable solution for windows apps. Haven't tested this on a
web app; I hope it's a different story.
 
jester said:
The subject says it all; I have a windows app that connects to a db. If I
run two instances of the same exe in the same machine, then two connection
pools are created in the database server despite the fact that they use
exactly the same connection strings. MSDN docu doesn't mention this at all,
hence my request for confirmation. If that is indeed the case, then I guess
it's not a very scalable solution for windows apps. Haven't tested this on
a web app; I hope it's a different story.

It's per app-domain IIRC...

'Not very scalable' is untrue, as winform apps on desktops are not that
suitable for connection pooling anyway: say you have a database server and
200 desktop computers with your winform application targeting that database
server, that's 200 connections! You can't pool them as they are located on
different machines.

Frans.
 
Thanks for your thought, Frans. But some further clarifications though:
1. Re: the location of the conn pool, quoting the ADO.NET MOC, Module 2
Connecting to Data Sources (p.38): "Connection pooling occurs on the computer
where the database installed". I hope this is not another urban myth :(
2. And even on a single machine, you can have 2 apps that connect to the
same db using the same exact conn string. If those 2 win apps set the Min
Pool Size to 5, then you'll have 10 connections the first time those 2 apps
connect to the db.
 
jester said:
Thanks for your thought, Frans. But some further clarifications though:
1. Re: the location of the conn pool, quoting the ADO.NET MOC, Module 2
Connecting to Data Sources (p.38): "Connection pooling occurs on the
computer where the database installed". I hope this is not another urban
myth :(

The physical connection lives on the system where the connection is created
so pooling takes place there. Of course, a pool might also be used on the
server, but afaik, the pooling we're referring to is on the client.
2. And even on a single machine, you can have 2 apps that connect
to the same db using the same exact conn string. If those 2 win apps set
the Min Pool Size to 5, then you'll have 10 connections the first time
those 2 apps connect to the db.

OK, but is that a common scenario?

Frans.
 
you are correct, connection pooling is per app domain. for winapps, unless
your are hosting additional app domains, there is a pool per process. for
winapps, its often a good idea to turn pooling off, or limit the pool size.

in asp.net each vdir gets its own pool, so there is a pool per asp.net
website.

-- bruce (sqlwork.com)
 
Thanks for your insights, Frans and Bruce. I agree w/ Bruce on conn pooling
for win apps. I think a pool size of 1 per app should be reasonable, and
developers must be careful in setting Min Pool Size for win apps. As for web
apps, I've done my tests and I'm relieved to find out that 1 web app share
the connection pool, and not 1 connection pool per session (imagine how
catastrophic that would be). Haven't tried multiple web sites but I'm
contented for now. Thanks again, guys =)
 
Back
Top