Problems with Cached DBI connections

Edmund von der Burg evdb at
Mon Nov 13 20:27:04 GMT 2006

I think I saw something similar once. The database abstraction would
create a new connection if the current handle stopped responding to
'ping's, but would not actually delete all references to the
connection so it would not get destroyed.

Basically the connection was dead as far as $dbh->ping was concerned
but alive as far as the database was concerned. As each new connection
was made the available number got eaten up.

I'm not sure that this was the problem though. I made substantial
other changes that fixed other issues and this went away with them, so
not sure exactly what it was that was broken.

I'd suggest a DESTROY method on the handles that will tell you when
they get destroyed. This should let you know if they are being kept
around too long.


On 13/11/06, Simon Wistow <simon at> wrote:
> Has anybody else seen a phenomenom where they're using cached DBI
> connections but N processes run out of connections despite the fact that
> the DB (in this case MySQL - not sure if that's relevant) has a
> connection limit of M where N<M?
> FWIW "show processlist" shows that there are indeed M connections coming
> in but I'm not sure where from.
> Ideas? Workarounds? Fact of life?

In reality I'm evdb at -

More information about the mailing list