[Dbix-class] ROLLBACK seems to be skipped on 0.08

[Louis Erickson]

On Thu, 1 Nov 2007, Brandon Black wrote:

> On 11/1/07, Louis Erickson <lerickson at rdwarf.net> wrote:
> > I do have a question regarding txn_do, though, for I don't understand how
> > it can work properly with AutoCommit => 1.
<snip>
> > How does txn_do solve this?  This is the part I don't understand.  Perhaps
> > one of the experts here can explain it.

<snip>

> All of that aside, anyone who talks about "AutoCommit => 0" being a
> required for properly supporting multi-statement transactions with
> whatever appropriate level of transaction isolation is supported by
> the underlying DBMS is on the wrong track.
> 
> You can have the same multi-statement transactions with the same
> guarantees of serialization with or without AutoCommit at the DBI
> level.  At the DBI levels and below, all the way to your database,
> there is no difference between:
> 
> $dbh->{AutoCommit} = 0;
> $dbh->do("INSERT ...");
> $dbh->do("DELETE ...");
> $dbh->commit;
> 
> and:
> 
> $dbh->{AutoCommit} = 1;
> $dbh->begin_work;
> $dbh->do("INSERT ...");
> $dbh->do("DELETE ...");
> $dbh->commit;

Ah-ha!  There is a big thing in there that I didn't know about!  That 
little "begin_work" method is new to me, and serves a really important 
purpose here.  Using that makes real transactions possible, even with 
AutoCommit on.

A critical thing that I'd completely missed.  It's been in DBI since 2001, 
and I had never managed to run in to it before.

> However, for the abstractions DBIC is trying to support, AutoCommit=>1
> is really the only way to go.  AutoCommit=>0 would either require us
> to require all sql-generating code be in explicitly marked txns
> (marked by a begin_work-like call), which would suck for lots of
> existing modules out there, or if we didn't do so, would require us to
> somehow magically deal with ambiguously nested transaction contexts.
> AutoCommit=>1 doesn't suffer from these issues.

Sure, that makes sense.  The inability to do the more complex, multi-step 
transactions seemed like a glaring problem, and I was actually pretty sure 
that folks of the caliber I've seen around here wouldn't have missed it, 
but I didn't see the solution.

The explanations of why AutoCommit=>0 isn't going to mix well with DBIC 
were already pretty well hashed out, actually.  The only hole seemed to be 
multi-step transactions, and that is possible.  DBIC handles it, and I can 
make it happen on my own.  With that in place, I don't see any reason to 
struggle with AutoCommit=>0 compatibility either.

> As far as the DBIC-level txn api goes, "txn_do($coderef, at args)"
> basically does something like the following pseudocode from the user
> perspective:
<snip>
> However, nobody's come up with any sane example of
> anything they'd want to do with those calls that can't be accomplished
> via txn_do(), which saves you working out all the gory details
> yourself and probably handles things better.

I'd figured most of that out from the code.  I was all over it, debugging 
the transaction depths and figuring out what was going on, trying to make 
sure I wasn't doing something silly before I posted.  Either I missed the 
begin_work call, or it was in a helper function and I didn't realize it 
was a native DBI call.

The only other reason I'm using AutoCommit=>0 is some other non-DBIC code, 
but I can either open a separate DB connection for that, or use begin_work 
myself in it.  Or re-write it with DBIC, finally.  I'll probably do the 
latter, and then quit worrying about it.  (Or the separate connection, as 
that's very simple, and then a re-write next.)

Thank you *very* much for the clear reply!  It completely answered my 
question and resolves any concern I may have had.

-- 
Louis Erickson - lerickson at rdwarf.net - http://www.rdwarf.com/~wwonko/

It was one of those perfect summer days -- the sun was shining, a
breeze was blowing, the birds were singing, and the lawn mower was
broken ...
		-- James Dent