According to David E. Wheeler:
> Perrin Harkins wrote:
> >
> > My point was that Apache::DBI already gives you persistent connections,
> > and when people say they want actual pooled connections instead they
> > usually don't have a good reason for it.
>
> Let's say that I have 20 customers, each of whom has a database schema
> for their data. I have one Apache web server serving all of those
> customers. Say that Apache has forked off 20 children. Each of the
> customers who connects has to use their own authentication to their own
> schema. That means that Apache::DBI is caching 20 different connections
> - one per customer. Not only that, but Apache::DBI is caching 20
> different connections in each of the 20 processes. Suddenly you've got
> 400 connections to your database at once! And only 20 can actually be in
> use at any one time (one for each Apache childe).
>
> Start adding new customers and new database schemas, and you'll soon
> find yourself with more connections than you can handle.
Wouldn't this be handled just as well by running an Apache
per customer and letting each manage it's own pool of children
which will only connect to it's own database?
> And that's why connection pooling makes sense in some cases.
I think you could make a better case for it in a situation where
the reusability of the connection isn't known ahead of time,
as would be the case if the end user provided a name/password
for the connection.
Les Mikesell
[EMAIL PROTECTED]
