Several patches including 1205 deadlock victim retry logic, fixes for auto-reconnect, ensure finish statement handles

[jrafanie]

We have implemented several patches on top of 2_3_4 against rails and activerecord 2.2.2

see http://github.com/jrafanie/2000-2005-adapter/commits/2_3_4_patches

Here's a summary:

1205 "deadlock victim" retry logic at the transaction and single query level. Don't try to rollback the transaction on a 1205 since SQL server does this and just complains about a "rollback" without a "begin".

Convenience methods: spid, database version, product version, product level, product edition,

Apply lock timeout and transaction isolation level to a connection on initialize and reconnect

Don't auto-reconnect on commits, rollback, and in the middle of a transaction.

Ensure we finish the statement handles in a few places.

Of special note, the log method and transaction method both come from 2.2.2 and were modified to handle the 1205 deadlock victim errors. It appears that the transaction method has undergone many changes from 2.2.2 to 2.3.2. Oh well. We can work to get it into the mainstream adapter.

[metaskills]

Re: Joe:

Ken, much of the code is still very wet so use with caution. I wanted to post what we had as soon as it was usable. I have a few tests for the simple additions but not for the ones that are not easily recreated. The odbc rake test has the same passing results against the 2.3.4 adapter and with my changes.

Some of the patches have had some burn-in namely, setting the transaction isolation level/lock timeout on the connection on initialize and reconnect (but implemented for our needs), spid, and the convenience methods to get the various product version/level/editiion.

The major changes: 1205 retry, disabling auto reconnect for commits/rollback/in a transaction, and some of the ensure handle finishing have had very limited production use. It was only yesterday that we realized that the retry logic we put into the transaction method to handle 1205s was not working because the log method was changing our exception. As an aside about the log method, what in their right minds were they thinking when they change an exception raised at a lower level, do not keep the original exception's backtrace, and re-raise a different error?

As I noted in the ticket, the transaction method, which we copied from 2.2.2 AR, was changed slightly to only issue a rollback if the exception was NOT a 1205. This would have to merged with the 2.3.4 AR code or handled somewhere else to prevent a rollback on 1205.

[metaskills]

FYI, will still look at this soon, perhaps ya'll can make sure to rebase your fork to current too so that it will help me pull them in?

[jrafanie]

Ok, had a few issues merging but it's in. I created a new branch since I'm still new to git and did a git fetch of your remote branch changes, rebased them in, and couldn't push it back... I guess I should have done a git pull.

Anyway, here's the new branch:
http://github.com/jrafanie/2000-2005-adapter/commits/1205_issue_31/

[metaskills]

FYI, I'll have to get to this one on the next release.

[jrafanie]

Ken, I have rebased again and applied my changes on top of this commit:

commit 6d693a0
Author: Ken Collins ken@metaskills.net
Date: Tue Apr 27 15:03:55 2010 -0400

Better IronRuby docs, release 2.3.5.

http://gist.github.com/389700

[jrafanie]

Sorry, gist is found at:
http://gist.github.com/389706

[jrafanie]

As I mentioned previously, the log and transaction methods are from AR 2.2.2 so we may need some creativity to get it to work for all versions.

[metaskills]

@jrafanie Have you ever see an error like this after a deadlock?

Incorrect syntax near '-'.: SAVE TRANSACTION active_record_-1

I was basically debugging a few of these errors in our app today and hypothesized that it was related to the latest 2.3 adapter not recovering from a deadlock (maybe a lost connection) correctly and leaving the transaction count in some bad state. Thoughts?

[jrafanie]

@metaskills I have not seen this before. We have certainly encountered deadlock victim errors as you see by this feature request but this error just looks strange. Where is active_record_-1 coming from? I suppose if some part of the 2.3.8 code encounters an error that it doesn't handle properly, it could try creating a savepoint and gets an error like this. I would be interested to see if you had any prior transaction information either from sql server or the rails log.

[metaskills]

Closing this on out in favor of #150