[Dbix-class] transaction depth not reset in 0.08003

[Brandon Black]

On 7/18/07, Jonathan Tweed <jonathan at tweed.name> wrote:
> On 18 Jul 2007, at 20:11, Brandon Black wrote:
>
> > On 7/18/07, Richard Jolly <Richard.Jolly at bbc.co.uk> 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