perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bunce <Tim.Bu...@pobox.com>
Subject Re: mod_perl2 DBI handle freshining problem solved "once and for all"...
Date Thu, 02 Feb 2006 13:25:23 GMT
On Wed, Feb 01, 2006 at 02:06:22PM -0800, Tyler MacDonald wrote:
> Perrin Harkins <perrin@elem.com> wrote:
> 
> > You have to expect certain basic things to work, and one of them is that a
> > connection which can't be ping'ed is not holding a table lock.
> 
> 	I completely disagree. Here's some more conjecture: What if you
> can't ping the connection because of a temporary TCP/IP problem (eg;
> somebody tripping over the network cable)... the driver's ping timeout could
> easily expire before the TCP/IP stack's timeout expires, the cable coule be
> plugged back in, and then TCP/IP's happy, DBI experienced a ping timeout,
> but the connection is not technically "closed". If this can happen on my SSH
> sessions when my daughter yanks on my network cable, it could certainly
> happen on a database driver.
> 
> 	And here's some more conjecture: What if the ping just times out
> because the server is really, really busy?
> 
> > If it is, this is a much lower-level bug than DBI should try to deal with.
> 
> 	If DBI doesn't plan on using a cached database handle anymore, it
> should at least disconnect() it and remove it's dangling reference from
> CachedKids. I don't know if it does an explicit disconnect() itself in this
> case, but I do know the handle reference (which is essentally garbage at
> this point) is left laying around.

I agree that it would be reasonable for $dbh->disconnect() to remove
the handle from CachedKids.

> > > 	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.
>
> > Apache::DBI overrides disconnect() to be a no-op, and connect_cached()
> > doesn't.  (But Apache::DBI doesn't do this during startup.)

It would be reasonable for Apache::DBI to provide a way for applications
to call disconnect() and have it actually disconnect.

> 	Yeah, I ditched Apache::DBI early in diagnosing this problem. Then I
> wrote that hack to solve it, which is what has started this whole thread. I
> was happy just posting the hack and leaving it at that, but you guys keep
> egging me on ;-)

Like detectives egging on the chief witness :)

Tim.

Mime
View raw message