develooper Front page | perl.dbi.users | Postings from December 2012

Re: Possible database handle leak in DBI?

Thread Previous | Thread Next
Duncan McEwan
December 5, 2012 03:33
Re: Possible database handle leak in DBI?
Message ID:

> So to summarize, you are seeing that sometimes connect_cached uses 
> a previous entry, and sometimes it does not, right? ...
> ... When the connect_cached fails with a false negative, it is because
> the CachedKids hash is empty, when it should have at least one existing
> item, right?

Good summary!  Yes, the problem only occurs occasionally.  Based on the
debugging I have in, out of approx 160,000 calls to connect_cached()
over the last 2 days, the problem occurred around 360 times.

> I'd bump up the trace level to at least 3 ...

I had thought about turning on DBI tracing but I was a bit worried about
the amount of output that would be generated.  But having just read the
"TRACING" section of the DBI pod I see that I can also specify that I only
want to trace the connection process, so maybe it won't be so bad.  I'll try
it and find out!

> or at least check out the clear_cached_kids function inside of DBI.xs
> and get some debugging there to see who is clearing that cache ...

Delving into the C code was also something I was hoping to avoid, but if
turning on DBI connection tracing doesn't reveal anything I'll have a
look at that.

> As far as DBI itself, I 
> think only destroying a handle will call that function, and that 
> function is the only thing that will empty out {CachedKids}.

Sounds reasonable.  I'll see if debugging or code inspection reveals any
way that a handle could be destroyed without the connection being closed.

> The other thing to consider is the web app. I know that Apache::DBI/
> modperl has a lot of special rules regarding connecting and reconnecting:
> it's possible your fastcgi does as well.  You might also want to poke
> around with the mysql_auto_reconnect setting; it's possible it is on and
> causing issues.

Yes - I did see a test for the GATEWAY_INTERFACE env variable in
DBD::mysql::connect() which causes the mysql_auto_reconnect setting to be
turned on.  That was the only reference I found (in the perl code at least)
to that environment variable.  From what I could make out, if MOD_PERL is set
a whole different connection procedure is invoked using Apache::DBI::connect,
but that doesn't seem to be the case if running under fastcgi.

Anyway, thanks for the pointers.  I'll report back with any extra information
I find.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About