Ah, yes, I didn't consider that one. Thanks for pointing that out. BEGIN TRANSACTION a;
[various DML commands] BEGIN TRANSACTION b; [various DML commands] ROLLBACK; [various DML commands] COMMIT; Should commit "a", but not "b". That's a scenario I hadn't encountered before. I use classes that encapsulate business logic and data persistence which use transactions. One object may call various other objects, which use transactions themselves and hence I need "half-baked" nested transaction) but if anything fails, I always consider the most outer transaction a failure as well -- if for no other reason than the technical limitations of my db wrapper. ;) -----Original Message----- From: Igor Tandetnik [mailto:[EMAIL PROTECTED] Sent: Thursday, November 03, 2005 1:21 PM To: SQLite Subject: [sqlite] Re: BEGIN TRANSACTION name 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
