Question

Right now I have a C++ client application that uses mysql.h to connect to a MYSQL database and have to preform some logic in case there is a disconnect. I’m wondering if this is the best way to reconnect to a MYSQL database in a situation where my client gets disconnected.

bool MYSQL::Reconnect(const char *host, const char *user, const char *passwd, const char *db)
{
bool out = false;

pid_t command_pid = fork();
if (command_pid == 0)
{
    while(1)
    {
        sleep(1);
        if (mysql_real_connect(&m_mysql, host, user, passwd, db, 0, NULL, 0) == NULL )
        {
            fprintf(stderr, "Failed to connect to database: Error: %s\n",
            mysql_error(&m_mysql));
        }
        else
        {
            m_connected = true;
            out = true;
            break;
        }
    }
    exit(0);
}

if (command_pid < 0)
    fprintf(stderr, "Could not fork process[reconnect]: %s\n", mysql_error(&m_mysql));

return out;
}

Right now i take in all my parameters and preform a fork. the child process attempts to reconnect every second with a sleep() statement. Is this a good way to do this? Thanks

Answer 1

Sorry, but your code doesn’t do what you think it does, Kaiser Wilhelm.

In essence, you’re trying to treat a fork like a thread, which it is not.

When you fork a child, the parent process is completely cloned, including file and socket descriptors, which is how your program is connected to the MySQL database server. That is, both the parent and the child end up with their own copy of the same connection to the database server when you fork. I assume the parent only calls this Reconnect() method when it sees the connection drop, and stops using its copy of the now-defunct MySQL connection object, m_mysql. If so, the parent’s copy of the connection is just as useless as the client’s when you start the reconnect operation.

The thing is, the reverse is not also true: once the child manages to reconnect to the database server, the parent’s connection object remains defunct. Nothing the child does propagates back up to the parent. After the fork, the two processes are completely independent, except insofar as they might try to access some I/O resource they initially shared. For example, if you called this Reconnect() while the connection was up and continued using the connection in the parent, the child’s attempts to talk to the DB server on the same connection would confuse either mysqld or libmysqlclient, likely causing data corruption or a crash.

As hinted above, one solution to this is to use threads instead of forking. Beware, however, of the many problems with using threads with the MySQL C API.

Given a choice, I’d rather use asynchronous I/O to do the background connection attempt within the application’s main thread, but the MySQL C API doesn’t allow that.

It seems you’re trying to avoid blocking your main application thread while attempting the DB server reconnection. It may be that you can get away with doing it synchronously anyway by setting the connect timeout to 1 second, which is fine when the MySQL server is on the same machine or same LAN as the client. If you could tolerate your main thread blocking for up to a second for connection attempts to fail — worst case happening when the server is on a separate machine and it’s physically disconnected or firewalled — this would probably be a cleaner solution than threads. The connection attempt can fail much quicker if the server machine is still running and the port isn’t firewalled, such as when it is rebooting and the TCP/IP stack is [still] up.