On 7/18/07, Jonathan Tweed <[EMAIL PROTECTED]> wrote:
On 18 Jul 2007, at 20:11, Brandon Black wrote:
> On 7/18/07, Richard Jolly <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> We've just been trying upgrading to 0.08003 from 0.07000. Mostly
>> fine,
>> but one problem with transactions. If a transaction fails the
>> transaction depth is not reset. The end result is that if you have
>> two
>> failing transactions in a row, the second is actually not in a
>> transaction.
>>
>
> Someone mentioned this on irc the other day too. I've made a little
> bit of headway, in that the source of the problem seems to be that
> $dbh->{AutoCommit} seems to have the wrong value. I haven't figured
> out why yet, but if you put in some debugging (print STDERR)
> statements in Storage::DBI in the txn_* funcs, you can see
> $dbh->{AutoCommit} being false when it should be true...
Yeah this is exactly what we were seeing (I work with Richard).
AutoCommit was somehow an empty string rather than 1, which meant
that transaction_depth wasn't getting reset to 0. As to what's
causing that we have no idea.
Well, I've tracked this down a little bit further now. I had poorly
assumed $dbh->{AutoCommit} would statically remain at whatever value
it was set to (or defaulted to) at DBI->connect time. As it turns
out, $dbh->begin_work turns off the $dbh->{AutoCommit} value, which is
what's causing the confusion. I've patched trunk locally to grab a
copy of AutoCommit right after ->connect as a storage object
attribute, and have the rest of the code pay attention to that, and it
definitely makes t/81transactions.t happier. I'm still smoothing out
some related issues that it made apparent though.
-- Brandon
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/dbix-class@lists.rawmode.org/
