Marcus Welz wrote:
So, couldn't SQLite simply internally keep track of nested transaction through a counter that is incremented every time "BEGIN TRANSACTION" is encountered and decremented whenever "COMMIT" is encountered, and only truly COMMIT when that counter has reached 0 again?
Commits are easy, rollbacks are the tricky ones. If a nested transaction rolls back, you would expect the database to return to the state right before this nested transaction started, and be able to proceed with the outer transaction. That would mean introducing some kind of checkpoints in the journal. It would also mean the journal would have to be able to keep multiple versions of some pages (an outer transaction modified a row, then nested one modified the same row, then nested was rolled back). I imagine this is non-trivial.
Igor Tandetnik
