On Wed, 2006-02-01 at 11:27 -0800, Tyler MacDonald wrote:
> I am opening a handle before apache forks. However, I was
> able to verify that Apache::DBI wasn't loaded yet at that point (no
> $INC{'Apache/DBI.pm'}), and I was issuing a disconnect() before the fork
> took place.
If Apache::DBI wasn't loaded yet at that point, it won't work. It has
to load before DBI in order to work.
> So then I got rid of Apache::DBI entirely, deciding to rely
> entirely on DBI->connect_cached to do it's own pinging and reconnecting.
I have recently switched to doing it that way too.
> No
> such luck. Inexplicably, I'd get a dead handle back, that said something
> like "postgres server shutting down during query" (I don't have the exact
> error message anymore, but it was something like that).
That doesn't sound like a dead handle to me. It sounds like a handle
that is active, but won't work because it is being used in multiple
processes.
> ... so *then* I tried explicitly calling disconnect() on
> these handles if ping() fails. disconnect() would fail because the handle
> was "already disconnected", and the handle did *not* disappear out of
> CachedKids.
As Tim pointed out, it doesn't need to be removed from CachedKids for
this to work.
> Maybe Apache::DBI should push a PostConfigHandler into the
> server that disconnects *every* DBI handle active before apache forks?
It already has code that prevents handles opened during startup from
being cached at all. If that code has bugs, it should be fixed. It's
possible that a PostConfigHandler is more robust, but I don't think
there's any equivalent for mp1.
> Is
> there a valid use case for having the same DBI handle replicated across a
> bunch of apache child processes?
I think the Sybase driver can do this safely under certain conditions,
but generally no.
> When Apache::DBI refreshes it's database handle [~line 127],
> it doesn't look like it's disconnecting the old one. What if the old handle
> is in a connected, but unpingable state?
For this purpose, "connected" and "pingable" are the same thing.
> Why is Apache::DBI maintaining it's own cache in the first
> place? Shouldn't DBI->connect_cached be able to maintain that for us?
Apache::DBI could be changed to rely on connect_cached internals, but it
pre-dates connect_cached by years. It also does important things that
connect_cached doesn't do, like automatic rollbacks and voiding
disconnect() and not caching handles during startup. (I didn't want to
the disconnect behavior, which is why I stopped using Apache::DBI.)
> Is there an easy way to enumerate *all* cached database
> handles in DBI?
See ChildHandles in a recent DBI.
> As far as Tim's comment about "saving the world", I never
> realised that would become a full time job of it's own. ;-) I'm willing to
> refactor Apache::DBI when I have time (maybe even tonight).
At this point, I think we don't know what the problem was with your
database connections, and I'm not convinced it was a result of an
Apache::DBI bug. I do think it would be cool to change the code in
Apache::DBI to use connect_cached for some of the caching mechanics,
although that would require changes in DBI as well.
- Perrin
