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? :).