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:BI 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:BI 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 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, th=

e
> > PerlInitHandler phase happens for every request, and not just when thre=

ads
> > are created.

>
> I called it PerlInitHandle, but it's actually called
> PerlChildInitHandler. It's described here:
> http://perl.apache.org/docs/2.0/user...PerlChildInit=

Handler_
>
> 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 t=

his
> > 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
>
>