Daniel Kinzler daniel@brightbyte.de wrote:
So, my current proposal is a more expressive high-level api for transaction control consisting of start/finish/flush (and perhaps abort) on top of the low level interface consisting of begin/commit/rollback. Documentation needs to be very clear on how they behave and how they relate to each other.
I did some application (in Zope) where correctness was more important than locks and it was running on PostgreSQL so we never had this problem. Zope collects all transactions from different sources (multiple database connections for example) and handles them transparently (like automatic rollback on error/exception n the code). In MediaWiki context that would be equivalent to keeping transactions controlled at the WebRequest level. I know too little about InnoDB transactions to comment as I understand MySQL is very different.
For the short term, I suggest to suppress warnings about nested transactions under some conditions, see my previous response to aaron.
In includes/db/DatabasePostgres.php there is PostgresTransactionState monitor, which is very nice to debug all problems with implicit/explicit transactions. It can easily be abstracted (to Database.php or somewhere else) and maybe there are functions to monitor InnoDB transaction status as well.
From the PostgreSQL side I see one problem with nesting - we are already
using savepoints to emulate MySQL's "INSERT IGNORE" and friends.\ It might be difficult to abuse that feature for something more than this. There is a class "SavepointPostgres" which is used for that.
//Marcin