On Fri, 2004-08-13 at 17:05, John Siracusa wrote: > 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? It is possible on unix systems to pass filehandles between processes, but that kind of C programming is not something I'm likely to tackle myself. > With the Apache::DBI system on a typical db-backed web site, the max number > of simultaneous (mod_perl) requests is pretty much limited by the max number > of simultaneous open database connections (since, long term, every apache > child will be hanging onto at least one db connection). You actually have a site where you can run more apache children than database connections? I have never seen such a beast. IMO the only real advantage of having pooling over the way things are now (assuming you run a front-end proxy for static stuff) is that sites which use different database logins for each user will be able to use persistent connections. Right now, that would result in a very large number of connections. > Maybe that'd lead to too much contention, I don't know, but I assumed > something like that was a long-term mod_perl2/apache2/perl6 goal. Or maybe > it's just a personal fantasy... :) Perl6 would presumably mean mod_perl 3. Anyway, the pooling thing is mostly driven by how much Java people hype it. The usefulness of pooling is pretty limited for a site that actually uses database connections on every request. - 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
