|
From: Robert J. <yad...@sn...> - 2007-01-08 13:39:55
|
At 01:50 AM 1/8/2007, Mike Schilli wrote:
>By the way, you might want to take a look at mysql_auto_reconnect
>[snip] wouldn't this solve your problem?
Perhaps it would. I have to find out what happens when
mysql_auto_reconnect is turned on, but the actual database or network
connection is truly down. Turning on reconnects within Appender::DBI
caused my perl programs to block while waiting for the reconnection
-- defeating the purpose of the queuing mechanism (i.e. don't block
when the database is down!)
I think another problem with my existing code is that the connection
my wrapper makes is totally separate from the connection that
Appender::DBI makes. So even if my wrapper notices the disconnect
and makes the reconnection -- Appender::DBI still has to
reconnect. I still don't know why Appender::DBI failed to reconnect,
but if the connections in my wrapper and the appender are separate, I
can see that it makes the probability of error higher.
Perhaps the answer is to write a true subclass of Appender::DBI
instead of the kludge I came up with. I think I can just override
the log() method with my own with something like:
# Begin simplistic Pseudocode
sub log ()
{
if (not connected2database() ) {
# Connection is down
buffer_message()
} else {
write2database(@buffered_messages)
}
}
sub connected2database
{
if (not $dbh->ping() )
{
# try to reconnect - once
eval { connect() }
if ($@) {
# connection successful, rebuild statement handle
return 1;
} else {
return 0;
}
}
}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Jacobson ..........................
Flight Ops. Team Solar Dynamics Observatory (SDO)
............. ..............
|