Even without threads, wouldn't you rather have each apache child pulling connections from a shared, server-wide pool rather than holding onto at least one connection a piece whether they need it or not?
Sure. Can you figure out a way to do it?
Probably not in Perl 5 and apache 1.x, but I hope Perl 6, apache 2, and mod_(perl6|parrot) will be flexible enough...
It's not a matter of flexibility, but rather one of difficult coding and potential issues with closed source database client libraries. The coding would be in C, and it would involve passing data structures and open sockets between running processes. It's way beyond my level of unix-foo, but if someone out there wants to try it, there is nothing needed for it that hasn't already been there for years.
Making DBI::Pool work for threads is probably easier, and that could also be done today if someone has both the incentive and the C-coding skills to deal with the threading and XS issues.
I've worked on sites that use a "session" (MySQL) database connection on every request, but don't use a "main" (Postgres) database connection nearly that often.
In that situation, if a significant percentage of requests need sessions but not the main database, and the difference is determined by URL, I would move the session-only requests to a separate server.
Pooling sounds nice, but is a non-trivial problem, and only helps in a few specific situations. In the common case, where every request to the app-server needs a database handle, it is not very useful.
- Perrin
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
