Re: DBD::mysql::st execute warning

[prev] [thread] [next] [Date index for 2005/01/05]

Thanks everyone for the help.  Here's what I've learned so far...

What I'm seeing is consistent with The Morning Bug.  I added a call to
ping the DB every few hours, and my process did not crash this AM.

If I restart mysql as Perrin suggested, the problem returns.  So I need
to add some code to test the connection every time before it is used. 
Not sure where to do that exactly but hopefully I'll be able to
determine.

I'm not using apache and mod_perl, by the way.  Just my own app using
Class::DBI.

Thanks again, I'll post more (hopefully a resolution) as I learn it.

-Dave


On Mon, 03 Jan 2005 17:38:42 -0500, "Perrin Harkins" <perrin@xxxx.xxx>
said:
> On Mon, 2005-01-03 at 01:51 +0000, Scott McWhirter wrote:
> > I've come across this recently and the
> > main fix is to implement a "ping" subroutine since mysql doesn't
> > implement one itself.
> 
> According to the ChangeLog, MySQL has had a ping subroutine for
> something like 6 years.  You should not implement your own.
> 
> > Also things like caching statement handles without
> > using "prepare_cached" is a very bad thing.
> 
> It looks like Ima::DBI does the right thing there, calling
> prepare_cached() each time you ask for the handle.  The symptoms though
> point to a cached statement handle that tries to use a database
> connection that has gone away.
> 
> > In the main, it looks more like a DBI/DBD problem rather than a
> > Class::DBI one.
> 
> I don't think so.  DBI/DBD::mysql do the right thing when you call
> connect_cached() and prepare_cached(), so this most likely is caused by
> a statement handle getting kept around someplace in Ima::DBI or
> Class::DBI.
> 
> I'd suggest a bit more debugging by manually dropping and restarting the
> mysql server after a few requests, and seeing if it can pick up
> correctly.  It's probably a good idea to add some extra debugging into
> the Ima::DBI code to see if it is calling the right things (doing the
> ping and prepare_cached) in the request where you have the problem.
> 
> - Perrin
>