I am using mysql_auto_reconnect to ensure that my long running process can reliably interact with mysql. Here is the code I use to execute statements and account for auto reconnects.
I am using mysql_auto_reconnect to ensure that my long running process can reliably interact with mysql. Here is the code I use to execute statements and account for auto reconnects.
I've tested this functionality by establishing the connection, then killing the database process, then attempting to execute a statement. The first execute fails as expected, with a "lost connection" error, and DBD::mysql automatically reestablishes the connection so that the 2nd execute will work.
The problem is, when I leave it for long periods, the first execute fails, AND the 2nd execute fails, both with the "MySQL server has gone away." error message. mysql_auto_reconnect does not seem to have an effect in this case.
I don't understand the point of mysql_auto_reconnect if it doesn't reconnect in the "server has gone away" case.
In general, there is no problem with installing modules to a home directory. However, in the case of DBD::mysql, it can be tricky, because you need to compile it, and you need to have the mysql header files and libraries available. Some hosting providers don't provide compilers, which complicates things. If you have a system that is very similar to the one used by the hosting provider, you might be able to compile it at home and then just copy the files with some luck.
Other than that, perhaps you can work around it in your perl code by reconnecting explicitly. You can use $dbh->ping to check if the conection is live, and then reconnect if it's not. Since you need to check all the time, it would be a good idea to encapsulate $dbh in a method or subroutine. For example,
Thanks for your help itub! I ended up being able to build and install the latest version of DBD::mysql in my home directory and now the auto reconnect is functioning as expected. I guess I should RTFChangelog next time! :D
About your idea of reconnecting explicitly. I found one downside to this method, which I was using before I found out about mysql_auto_reconnect. Any statement handles that I had prepared before the disconnect needed to reprepared after reconnecting. When using mysql_auto_reconnect, it seems that I do not need to reprepare any of the statements. I could be wrong about this, but this is what I understood to be the case from my testing.
And one last note... it would be nice if mysql_auto_reconnect reconnected AND reexecuted statements. It seems a little silly to me to have to EXECUTE, test for a lost connection, then EXECUTE again if the connection dropped. I understand that this could be "dangerous", as losing the connection does not necessarily mean that the statement wasn't executed. At the same time, for the application I am developing, it's fine if the statement happens to execute twice, especially given that this would be a VERY VERY rare case. Just a suggestion to anyone who is listening ;)
Thanks for the tips about the explicit reconnects; I didn't know because I had never tested that in practice. ;-)
it would be nice if mysql_auto_reconnect reconnected AND reexecuted statements.
This is what the documentation claims, and it seems to work for me...
DBD::mysql has a "reconnect" feature that handles the so-called MySQL "morning bug": If the server has disconnected, most probably due to a timeout, then by default the driver will reconnect *and attempt to execute the same SQL statement again*. However, this behaviour is disabled when AutoCommit is off: Otherwise the transaction state would be completely unpredictable after a reconnect.
by default the driver will reconnect *and attempt to execute the same SQL statement again*
This has not been my experience.
After testing this repeatedly, I have determined that the 1st execute that fails due to a lost connection does nothing. The connection is not even re-established!!!
If I attempt the same execute again, it is this 2nd execute that reconnects and successfully executes the statment.
Is your experience with mysql_auto_reconnect different?
What would be ideal is for connection issues to be entirely contained in DBD::myql, so that I can issue a single execute call, and it will always work, regardless of the current database connection status.