We have a large site/application under construction in Ruby/Rails. The site is currently running on Debian Etch 64 bit linux, and rails 1.2.2. This problem is unchanged from rails 1.6 however (I upgraded in the hope it would get fixed). We are using the C "mysql" gem library (latest version).
The database is MySql, 5.0.30. Tables are all Inodb. We currently have 2 databases connected, although 1 contains only a log table is is not used in the main application.
In summary I have been completely unable to get transactions to work in a reliable manner.
Using ActiveRecord::Base.transaction &block to surround transactions, we frequently get "Mysql server has gone away" durring the COMMIT command. Without transactions there are no problems (other than the fatally bad lack of transactions). With them, they fail to commit approximately 10-20% of the time. The commit will fail, throwing a "mysql gone" exception (which is normally caught by the commit_db_transaction function). Doing an ethereal trace on the communication between rails and the db discovers that rails has issued a QUIT directive in the middle of the transaction!!
Despite having studied the code in the abstract adapters and the mysql adapter in much greater depth than I would ever like, I have not found any reason why this should happen.
Anyone have any clue what is going on? Are people using transactions in this configuration with any sucess?
As an additional tidbit, or perhaps no relevance. I tried rewriting my own version of the transaction method, using the underlying XX_db_transaction functions. This doesn't get the error but seemingly completly ignores my transactions (even though they are issued in the SQL logs). The normal transaction method works (80% of the time).
Thanks, Andy Gavin Flektor, Inc.