For the record in the hope that somebody may find this helpful.
I finally figured out the problem was simply the wait_timeout value was too
small ( 10 seconds).
The Problem:
Perl would die after a “prepare” call and before execute would return
a DBI trace ended with “my_login skip connect”. No error messages were sent to
the application or system error log. The rather strange part was that it would
stop on different transactions, given different data sets. But usually the same
transaction for a given data set.
Background:
This took weeks to track down, in part because it was running on a hosted
system. There was no access to the mysql error log so I don't know if that
would have offered a clue. The hosting service claimed they had only upgraded
the Perl version and had not touched anything else. The application ran fine on
in-house systems so we could not duplicate the problem except on the hosted
system.
Lessons Learned:
In a hosted environment make sure you have a record of the MySQL version, and
the system variable settings. The host service can change these at any time,
and may not even be aware of it. When a working system stops working, the first
thing I would now do is check the working system variables, against the current
system variables.
P.S. Thanks to Clive for his Red Hat/Perl post. In the middle of all this I
switched hosting services to one that uses CentOS, and I can't believe how slow
it is.
__________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
favourite sites. Download it now at
http://ca.toolbar.yahoo.com.
