Repository navigation
Engine: statement-level savepoints, so a failed multi-row statement inside a transaction is undone on its own #10346
Description
Follow-up to #10194 (third point).
Inside a transaction the caller keeps, a multi-row statement that fails midway leaves the records it wrote before the error. SQLite undoes the failed statement and lets the transaction go on. The fix for #10194 does not do that: with no savepoint to go back to, it marks the transaction rollback-only when a statement fails after part of its records were written, so the commit throws and nothing is published (the answer a half-applied delete already gets, #9305). A caller that catches the error of a multi-row statement and wants to carry on with the rest of its transaction cannot.
What a real statement savepoint has to restore (TransactionContext): the modified and new pages, the record caches and the updated-record queue, the new/deleted record sets, the index lanes of TransactionIndexContext, the bucket record deltas, the slot-merge and edge-append buffers and their poisoned-page sets, the insert reservations, the off-page fingerprints, the unidirectional edge changes, and the vector overlay.
Constraints for a design:
- the statement that owns its transaction (auto-transaction) must pay nothing, since it rolls back whole;
- inside a caller's transaction the copy of a page is needed only for a page the transaction had already modified before the statement, so the cost is bounded by the pages the statement re-touches;
- events already fired cannot be taken back.
Once it exists, the rollback-only guard in SQLQueryEngine (refuseCommitOfHalfAppliedStatement) can be replaced by a rollback to the statement's savepoint.
Activity
review(#10346): a guard test that every field of TransactionContext i…
review(#10346, #10507): a savepoint refused for a broken index journa…
review(#10346): PageUndoLog declares its nested interface after its m…
review(#10346): the scan a statement made for incoming unidirectional…
review(#10346): a test that takes every kind of failing statement bac…
review(#10346): a statement that could not be taken back and changed …
review(#10346): a page log that ran out of budget refuses to restore,…
review(#10346): the release notes say a schema change of a failed sta…
23 remaining items
review(#10346): a statement past the granule budget is refused before…
review(#10346): a delete is counted before its after-delete listeners…
review(#10346): one page log reused for pages of different sizes star…
review(#10346): a statement that cannot be taken back for any reason …
review(#10346): a callback registered for the commit by a statement t…
review(#10346): the growth of the page log says what bounds it, the f…
review(#10346): an after-delete listener sees the counts with the del…
review(#10346): the journal limit and disabled tests assert the reaso…
review(#10346): a write statement of SQL and openCypher runs to its e…
review(#10346): a taken-back delete with a failing listener leaves th…
fix(#10521, #10507, #10346): a failed statement inside a transaction …
lvca commentedon Oct 22, 2026
Fixed in #10572 (26.11.1).
A statement that fails inside a transaction you keep open is now taken back on its own, and the transaction goes on: you can catch the error, run another statement and commit the rest. Before, the commit was refused.
When a statement cannot be taken back exactly, the commit is still refused, with the reason in the message: it changed more than
arcadedb.txStatementSavepointMaxEntriesentries (100,000 by default,0turns the feature off), it updated a record with anEXTERNALproperty that an earlier statement had updated, it changed records a Graph Analytical View follows, or it dropped a file. A Gremlin traversal keeps the old behaviour. Schema changes and events already fired are not undone.❤️ Thanks for helping make ArcadeDB better! ArcadeDB is free and open source, sustained by its community. If it's useful to you or your company, please consider becoming a sponsor to keep development going.
fix(#10521, #10507, #10346): a failed statement inside a transaction …