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) ............. .............. |