If you take a look at the thread at web/db, you'll see I've pointed out another whole area where transaction-busting seems to take place, i.e. the use of utility routines like ad_categorize_row inside transactions. In fact, the document suggest using multiple calls to ad_categorize_row in some cases, which the reader will naturally put inside a transaction, which naturally busts the transaction.
The paradigm I'm using myself is to build up a list of dml statements, then execute them all within a transaction at the top level:
set dml [list]
hammer_the_db $dml parameters...
hammer_it_again $dml parameters...
with_transaction $db {
foreach dml_stmt $dml {
ns_db dml $db $dml_stmt
}
} {...error handling...}
retaining the convenience of the utility routines while not screwing up transaction semantics by nesting "begin/end transaction" statements.
This could be made even simpler with a proc that takes a list of dml statements, called something like:
transact $db $dml {...error handling...}
where dml was built up as in my earlier example.
Comments?
I don't know if the aD folks are taking my reports seriously, though they will if they actually implement Jin's notion of having the driver flag an error if a "begin" dml statement is issued from within a transaction - they'll get errors all over the friggin' place if they do this.
