How should structurally-nested MySQL transactions be handled?
The MySQL docs state:
Transactions cannot be nested. This is a consequence of the implicit commit performed for any current transaction when you issue a START TRANSACTION statement or one of its synonyms.
Since 1.9.10, Kea no longer relies on this default behavior. Commits 4ba460d0 and 83a59894 have made it so that the statements belonging to the inner transactions are re-assigned to the outermost transaction. This is arguably better than the MySQL default, because the statements of the inner transaction keep their atomicity (and probably other properties that transaction ensure), instead of it being split into smaller atomic portions, like in the default scenario.
But... A side effect is that the result of the inner transaction is ignored. I don't see this being a problem in case the inner transaction would have committed. But it might be a problem if the inner transaction had decided to rollback. Post-1.9.10, if the outermost transaction decides to commit, the otherwise rolled back statements will now also be committed.
- prioritize rollbacks so that a rolled back inner transaction results in a rolled back outer transaction
- turn inner transactions (decided by an if branch in code) into savepoints:
- turn "START TRANSACTION" into "SAVEPOINT identifier"
- turn "ROLLBACK" into "ROLLBACK [WORK] TO [SAVEPOINT] identifier"
- turn "COMMIT" into "RELEASE SAVEPOINT identifier"