writing a bulletproof perl daemon with persistant mysql connection

Time is of the essence while sending "report" data back to a mysql database over the internet.  My goal is to write a bulletproof daemon that handles a constant connection to this database.

My server daemon pre-forks "worker" children to do time consuming work, and pre-forks a "reporting" child to handle sending reports from the "workers" back to the database.

In the "reporting" child I have a 60 second alarm signal inside of an eval{} statement that encloses the mysql database work.  No database work should take longer than a few seconds.  After a day or two of uptime, the "reporting" child hangs for approx 1 hour or more where nothing takes place and then the "reporting" child dies because of the alarm signal.  The eval{} statement is unable to trap the die().

I have 3 of these daemons running on different machines across the internet, and while 1 is hanging, 2 of the 3 are still able to report to the mysql database just fine.

Here is my code:

my $dbh;
eval {
      my $dsn = "DBI:$driver:database=$database;host=$hostname;mysql_connect_timeout=10";
      $dbh = DBI->connect($dsn, $username, $password, { RaiseError => 1, PrintError => 0, AutoCommit => 1 });
      $dbh->{mysql_auto_reconnect} = 1;
if( $@ ) {
      goto RECONNECT;

while( 1 ) {
      eval {
            #      Setup ALRM handler signal
            local $SIG{ALRM} = sub { die "timeout\n" };
            alarm( 60 );

            $dbh->do("INSERT INTO table_name VALUES ( data, ... )");

            alarm( 0 );
      if( $@ ) {
            if( $@ =~ /timeout/ ) {
                  print "Timed out\n";
            } else {
                  alarm( 0 );

When bad things happen, how would you go about setting up a daemon that has the best possible connection with the mysql server?
LVL 10
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Maybe you should just open a connection when you need to send a report in, then close it right after.  That way you don't have to depend on auto-reconnection behavior.  If you can deal with a 60-second lag before your alarm, the second or two it takes to connect every time should be trivial.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.