On Fri, 2006-04-07 at 21:16 -0500, David Nicol wrote: > When I was trying to multiplex a single database connection to a > room ful of clients that combination was reccommended to me by people > on the DBI list.
I suspect most of them have never tried it. It's a solution for accessing a database that has no client available on your platform, but it's not efficient. It doesn't even keep the connections to the database persistent, and every client connection still needs a separate process. Writing a pooling server that works as a proxy for all DBD's is pretty hard, since they all have different client libraries and protocols. A non-blocking I/O approach would probably work great, but you'd need non-blocking client libraries for all the databases. > If I was to write a DBI multiplexer that simply serialized requests in order > I would hope I was working against a database that could have multiple > open result streams at once I'm not sure where the idea of serializing requests came from, but that's not going to be a viable solution for anyone with significant traffic. All of the popular databases handle parallel requests very well. If you run a proxy server in front of mod_perl, there's typically no need to worry about pooling. Apache does a good job of managing how many mod_perl processes are running, and ones that don't hit mod_perl will not tie up database connections. The only exception is when you have mod_perl handlers that do a lot of work but don't need a database connection. Those could be isolated on a separate mod_perl server if necessary. - Perrin
