This comment has been minimized.

Supposedly reconnect true in the database.yml file will drop other environment configs such as utf8 when it reconnects. Did you ever figure out why the execute method is undefined? Having the same issue.

Supposedly reconnect true in the database.yml file will drop other environment configs such as utf8 when it reconnects. Did you ever figure out why the execute method is undefined? Having the same issue.

This comment has been minimized.

Is there any reason to use this in applications using ActiveRecord versions ~> 3.0 when you're taking care to call #verify_active_connections! before accessing the database?

ActiveRecord::Base.connection_handler.verify_active_connections!

I'm just wondering if these kinds of exceptions still crop up for people and reconnect code like this is necessary when the above technique is used to preemptively nuke stale connections from the connection pools?

Is there any reason to use this in applications using ActiveRecord versions ~> 3.0 when you're taking care to call #verify_active_connections! before accessing the database?

ActiveRecord::Base.connection_handler.verify_active_connections!

I'm just wondering if these kinds of exceptions still crop up for people and reconnect code like this is necessary when the above technique is used to preemptively nuke stale connections from the connection pools?

This comment has been minimized.

I found that this fix caused me a whole lot of trouble with data integrity when I upgraded to Rails 3.1 from 2.3. I don't know what changed between the two versions, but basically, my wait_timeout was set to 10 seconds. In the case that a single transaction took longer than that 10 seconds, the connection timed out returning the "sever has gone away" exception. This monkey patch would then catch that, reconnect, and retry the last statement that caused the exception. However, the first connection, which started the transaction, would have all of its statements rolled back due to the disconnect. So this patch's retry would cause the application to just chug along on subsequent statements not even knowing that the beginning statements had been rolled back. This led to child rows pointing to parent rows that did not even exist in the db (since the parents had been rolled back). I tested this out with a short wait_timeout: 5 in database.yml.

I found that a post row would be created with user_id = 1 even though no user rows existed. Now, when I removed the monkey patch in this gist and instead used reconnect: true, mysql2 seems to correctly restart the transaction and everything works out well.

I think reconnect: true is much safer since the mysql client has pre-defined behavior on what to do when a timeout happens: http://dev.mysql.com/doc/refman/5.0/en/auto-reconnect.html. Anyway, I hope this helps anyone else who may or may not have been bashing his or her head against the wall trying to figure out why their database integrity is wacky.

I found that this fix caused me a whole lot of trouble with data integrity when I upgraded to Rails 3.1 from 2.3. I don't know what changed between the two versions, but basically, my wait_timeout was set to 10 seconds. In the case that a single transaction took longer than that 10 seconds, the connection timed out returning the "sever has gone away" exception. This monkey patch would then catch that, reconnect, and retry the last statement that caused the exception. However, the first connection, which started the transaction, would have all of its statements rolled back due to the disconnect. So this patch's retry would cause the application to just chug along on subsequent statements not even knowing that the beginning statements had been rolled back. This led to child rows pointing to parent rows that did not even exist in the db (since the parents had been rolled back). I tested this out with a short wait_timeout: 5 in database.yml.

I found that a post row would be created with user_id = 1 even though no user rows existed. Now, when I removed the monkey patch in this gist and instead used reconnect: true, mysql2 seems to correctly restart the transaction and everything works out well.

I think reconnect: true is much safer since the mysql client has pre-defined behavior on what to do when a timeout happens: http://dev.mysql.com/doc/refman/5.0/en/auto-reconnect.html. Anyway, I hope this helps anyone else who may or may not have been bashing his or her head against the wall trying to figure out why their database integrity is wacky.

This comment has been minimized.

@agibralter: I did some reading on reconnect: true and it seems like it doesn't guarantee that the connection encoding will be set to utf8 on reconnection. Have you run into any latin1 character encodings?

@agibralter: I did some reading on reconnect: true and it seems like it doesn't guarantee that the connection encoding will be set to utf8 on reconnection. Have you run into any latin1 character encodings?

This comment has been minimized.

We tried the connection fix on a site that is running on Rails2.3.14 with a lot of traffic and run into all kind of strange locking issues on the database. Once we removed the fix, it was all fine again. Can't really explain why this happend.

So.. I have been looking for alternative solutions. I have seen people who suggested to add ActiveRecord::Base.verify_active_connections! to your perform. I used an alternative approach by using the after_fork hook inside resque.rb in the config/initializers folder.

We tried the connection fix on a site that is running on Rails2.3.14 with a lot of traffic and run into all kind of strange locking issues on the database. Once we removed the fix, it was all fine again. Can't really explain why this happend.

So.. I have been looking for alternative solutions. I have seen people who suggested to add ActiveRecord::Base.verify_active_connections! to your perform. I used an alternative approach by using the after_fork hook inside resque.rb in the config/initializers folder.

This comment has been minimized.

I had a bit trouble with the gist when migrating to mysql2 adapter. After checking the rails code I found out that the rails team implemented an AbstractMysqlAdapter so I changed the gist as follows. This should work with mysql and mysql2 adapter, right?

I had a bit trouble with the gist when migrating to mysql2 adapter. After checking the rails code I found out that the rails team implemented an AbstractMysqlAdapter so I changed the gist as follows. This should work with mysql and mysql2 adapter, right?

This comment has been minimized.

This would work both before & after forking the child, since it wouldn't close active connections, but it would check everything back in to the connection pool, and checking back out from the pool verifies the connections.

This would work both before & after forking the child, since it wouldn't close active connections, but it would check everything back in to the connection pool, and checking back out from the pool verifies the connections.