Hi,
this is a follow-up to the autocommit/JDBC thread. I thought
this post would better fit in a new thread.
I finally managed to solve the issue. Please forget my comments about
JDBC
drivers
and jar files, this had nothing to do with the problem.
It turned out that SQL exceptions happen when Rails tries to create the
fixtures for the
test-case (some FK violations).
But why is this autocommit exception thrown instead of the real problem?
After some
debugging (well, yesterday it was a rainy Sunday afternoon) I found out
that
Rails
fires two subsequent rollbacks, one additional in
“teardown_with_fixtures”
(fixtures.rb).
This is no problem with MRI/mysql_adapter since transactions are spanned
using
“begin”/“rollback”/“commit” and MySQL seems to silently ignore the
second
rollback.
With JDBC it’s different: After the first rollback the connection is set
back to
autocommit-mode. Now when the second rollback comes along, we finally
see
MySQL
complaining about the connection being in autocommit mode, completely
hiding
the
original exception.
To solve the problem I added a check to
JdbcAdapterInternalService.rollback() so
it doesn’t actually send the rollback to the database when the
connection
already
is in auto-commit.
Maybe there is a better patch, but so far everything seems to work.
Now to the original cause of the problem, the FK violations. These don’t
happen with
MRI/mysql_adapter. Rails 2.0 introduced “disable_referential_integrity”
while creating the
fixtures. This method is simply missing in the JDBC adapter.
To get it working quickly I simply added the method to the JDBC adapater
(though MySQL specific)
in my environment.rb:
if RUBY_PLATFORM =~ /java/
module ActiveRecord
module ConnectionAdapters
class JdbcAdapter
def disable_referential_integrity(&block) #:nodoc:
old = select_value(“SELECT @@FOREIGN_KEY_CHECKS”)
begin
update("SET FOREIGN_KEY_CHECKS = 0")
yield
ensure
update("SET FOREIGN_KEY_CHECKS = #{old}")
end
end
end
end
end
end
Now everything behaves like MRI/mysql_adapter!
One final note: While debugging I had a look at
JdbcAdapterInternalService.isConnectionBroken().
The method seems to return always true, indicating the connection is
broken.
Is this intentional?
I noticed that for some reasons multiple connections were created
(because
of withConnectionAndRetry()
and isConnectionBroken()). I changed this, too.
Anyway this retry mechanism looks dangerous to me, e.g. what happens
with
transaction state?
I will also add a comment to http://jira.codehaus.org/browse/JRUBY-2422
about this post.
Christian
–
View this message in context:
http://www.nabble.com/Autocommit-error-with-AR-JDBC---solved-tp17312245p17312245.html
Sent from the JRuby - User mailing list archive at Nabble.com.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email