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