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