perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler MacDonald <>
Subject Re: mod_perl2 DBI handle freshining problem solved "once and for all"...
Date Wed, 01 Feb 2006 21:22:59 GMT
Perrin Harkins <> 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/'}), 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.

	The point here was that I *wanted* the disconnect() to take place.
So I made sure Apache::DBI wasn't loaded when disconnect() was called before
the fork, so that it wouldn't trump my attempt to disconnect the handle
owned by the parent process.

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

	Perhaps, but how would that explain this paradox:

	- After receving this error, calling a disconnect() on the handle
says "handle already disconnected", yet:

	- After attempting to re-connect() or connect_cache() to the
database, the *new* handle also exhibits the same screwed up beahviour?

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

	Fair enough, but I still think it should always be removed from
CachedKids on disconnect(), even if the handle is already disconnected: to
prevent any driver-specific buffers it had from sitting around forever, or
it's DESTROY from being called at an unexpected time way down the road where
a potential error won't have enough context to debug, etc...

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

	Hmm. I'll chat with gozer about that and see if there's a way to
hack similar functionality in for mp1.

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

	Yes and no. If you can't ping the server, but the TCP socket is
still open, that means you essentially have this TCP connection to the
server that's not being used, in an open state, for the rest of the lifetime
of your apache server instance. This could be a Bad Thing, say, if it's in
mid-transaction, keeping a table lock open...

> 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.)

	When I just let a database handle fall off the face of the earth I
generally get a warning like "DESTROY: issuing ROLLBACK for handle destroyed
without disconnect". So it seems like a part of that logic is already in the
new DBI.

> > 		Is there an easy way to enumerate *all* cached database
> > handles in DBI?
> See ChildHandles in a recent DBI.

	Ah, I missed that. So installed_drivers only returns drivers you've
actually use()d at some point, and gives me handles for each? That's awesome

> 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 know that after refactoring my code to not use Apache::DBI at
all, and not depend on connect_cached() to behave properly, (adding the
PostConfig and PreConnection handlers to be very paranoid about what happens
to the handles), the problem has gone away.

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

	Hmm. What changes in DBI?


View raw message