Instead of connecting to the DB and having DBI cache the handle
after-the-fork, would it make sense to subclass Apache::DBI, have the
parent process create a defined number of connections, and then use
some sort of roundrobin/checkout to sign out a handle during a request?
You're asking "why?" and i'm responding that i dont really know
i just remembered that i'll likely have to up my connection limit to my
db based on the number of apache children - and i thought it would be
nice, in a way, to have something that forces me to be cognizant of how
many children i'm spawning within my webapp, not just in apache, so i
can just look at the application code and say "hm. i need x
connections" instead of looking through the apache configuration
