I've done some heavy DB work/testing and like your idea of simply turning off autocommit, rolling back for all the database tests. It's not what we did- we just truncated all the test tables to start from a good state, and the only parallel testing we did were specifically designed concurrency tests. Not saying that's what I'd do again, just for a data point.
Anyway, while rolling back after DB unit tests seems like a good solution in general, and is something I would try in the future, it can't work in all situations- specifically when you want to test things that rely on transactions. Part of our designed-to-be-concurrent tests had to do with subroutines that required a lock so changes to 2-3 tables would be either all done, or all rolled back on failure. Another needed an exclusive-select-row lock. Those needed to commit so we could both see the data succeed and so we could see the concurrent threads continue (or report "could not get lock" properly, etc) -y On Sat, May 4, 2013 at 4:37 PM, Buddy Burden <barefootco...@gmail.com> wrote: > Ovid, > > I lean more towards Mark's approach on this one, albeit with a slight twist. ...
