Daniel Kinzler
<daniel(a)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