fix: release START_TXN nesting level on persist() SQLException path (#13905) - #13925
fix: release START_TXN nesting level on persist() SQLException path (#13905)#13925waterWang wants to merge 1 commit into
Conversation
…pache#13905) GenericDaoBase.persist() calls txn.start() which pushes a START_TXN nesting level onto the caller's transaction stack. The SQLException catch block throws without reaching txn.commit(), so the nesting level is leaked. The caller's subsequent commit() finds the transaction unbalanced and silently no-ops — all caller work in that batch is lost with no error. Fix: track commit success and roll back the START_TXN level in a finally block when commit() was not reached, ensuring the caller's transaction is restored to a balanced state instead of silently abandoning its work. Closes apache#13905 Signed-off-by: waterWang <waterwang@proton.me>
36514dd to
a829bf1
Compare
| throw new CloudRuntimeException("Problem with getting the ec attribute ", e); | ||
| } finally { | ||
| if (!committed) { | ||
| txn.rollback(); |
There was a problem hiding this comment.
would it be possible to just rollback in the exception handlers instead?
There was a problem hiding this comment.
I'd keep the flag + finally over rollback-in-catch, for two reasons:
-
finally covers exception types the catch clauses don't. The try block does field reflection and SQL value coercion in a loop, so an unchecked RuntimeException (NPE, ClassCastException, etc.) could skip all three catch clauses but would still hit finally. Rollback-in-catch only protects SQLException/NoSuchFieldException/IllegalAccessException; finally protects the whole try block, which is the actual gap we're closing.
-
TransactionLegacy.rollback() isn't nesting-aware the way commit() is - it strips every START_TXN marker off the stack and does one physical rollback, so it needs to run exactly once per persist() call regardless of which branch got there. A single finally guarantees that; three (and eventually ~20+ once fix: release START_TXN nesting level on SQLException paths in GenericDaoBase sibling methods #13926 covers the sibling methods) separate call sites don't, and a future added catch clause could reintroduce the leak by omission - the same class of mistake that caused this bug.
Happy to reconsider if there's a case I'm missing, but I think the flag is earning its keep here.
|
also if we solve it this way, it should go on the oldest open LTS branch (4.20 atm) |
3 participants
Description
GenericDaoBase.persist()callstxn.start()which pushes aSTART_TXNnesting level onto the caller's transaction stack. When the insert throwsSQLException, the catch block rethrows without reachingtxn.commit(), so the pushed nesting level is leaked. The caller's latercommit()then finds the transaction unbalanced and silently no-ops (logging onlytxn: Commit called when it is not a transaction), discarding everything the caller believed it committed.Callers that deliberately catch
EntityExistsExceptionto log-and-continue cannot actually continue, because the enclosing transaction is already unrecoverable — this converts a single constraint violation into permanent failure (see #13399).Fix
Track commit success via a
committedflag; in afinallyblock, roll back the transaction when the commit was not reached, restoring the caller's transaction to a balanced state.Types of changes
How has this been tested?
Code-review level only — the change adds a rollback guard to the existing try/catch structure. Existing tests cover DAO persist paths.
Closes #13905