I want my modules to be able to get a the same database handle anywhere they need it during a single request (if under mod_perl) or the life time of the script they're in.
At first I was caching the database handle myself when running outside of mod_perl. In mod_perl I was relying on Apache::DBI returning the same handle every time I called connect(). That didn't work. Then I read a section in Appendix A of "Practical mod_perl" that gave me what I wanted: http://modperlbook.org/html/appa_12.html But doesn't that solution have this problem: It will return a dead database handle when the connection times out before the Child is reaped. In fact, that's just the problem that Apache::DBI solved by adding the ping() method. I considered allocating a handle in the pnotes() at the beginning of every request using a PerlInitHandler, but that is expensive, especially since many requests don't even use a handle. Jay On 5/8/06, Perrin Harkins <[EMAIL PROTECTED]> wrote:
On Mon, 2006-05-08 at 17:23 +0200, Lionel MARTIN wrote: > I'm not sure this is right. Acording to what I read, and to my test, the > PerlInitHandler phase happens for every request, and not just when threads > are created. I called it PerlInitHandle, but it's actually called PerlChildInitHandler. It's described here: http://perl.apache.org/docs/2.0/user/handlers/server.html#C_PerlChildInitHandler_ It does say that it only runs once per process. It should not run on every request. Despite the difference though, you're correct -- since it runs at the start of each process, not each thread, using connect_on_init() is probably not going to work with a threaded MPM. You should just call DBI->connect() from within your code instead. The first request in a new thread will take the hit of opening the connection. > The ideal would be to create the > connection when threads are started, create statement handles against this > connection, and keep all that until threads are killed. I'm not aware of a hook for the start of a thread. However, it's not a good idea to try to manage a cache of statement handles yourself. You should let DBI do this for you by using prepare_cached. That way, it will still work if your connection times out from inactivity and gets reconnected later. - Perrin
