On 25/09/12 13:38, Tim Starling wrote:
> On 25/09/12 19:33, Daniel Kinzler wrote:
>> So, can someone shed light on what DBO_TRX is intended to do, and how it is
>> supposed to work?
>
> Maybe you should have asked that before you broke it with I8c0426e1.
He did ask about the whole database transactions on Aug 23 ("Nested
database transactions thread"), and explicitely asked from objections
the next day. I8c0426e1 is from Aug 27.
Nobody said that «begin() and commit() were never meant to be "matched"»
on that thread, the previous one (2010) or even mails in the last few
years AFAIK. I guess that's because you were the only one who knew how
they were meant to be used. :)
(...)
> Initially, I set up a scheme where transactions were "nested", in the
> sense that begin() incremented the transaction level and commit()
> decremented it. When it was decremented to zero, an actual COMMIT was
> issued. So you would have a call sequence like:
>
> * begin() -- sends BEGIN
> * begin() -- does nothing
> * commit() -- does nothing
> * commit() -- sends COMMIT
>
> This scheme soon proved to be inappropriate, since it turned out that
> the most important thing for performance and correctness is for an
> application to be able to commit the current transaction after some
> particular query has completed.
Except when you break your caller, whose transaction you wrecked, with
bad consequences such as losing the descriptions of uploaded files (bug
32551).
As for the original issue, I think that it could be solved by leaving
the "transaction counter" at 0 for the implicit DB_TRX, and making
begin() commit it and create a new one when called explicitely (we would
need another flag... name that transaction level 0.5? :).
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
