On 24 November 2017 at 10:27, J. King <jk...@jkingweb.ca> wrote: > The rollback journal is used to return the database to its previous state > in the case of a partial write, not complete writes which are interrupted. > As you didn't commit the transaction, no write occurred, never mind a > partial one, so the database remained in its initial state. > > Deleting a rollback journal is a bad idea. In this case it was harmless, > but normally it's an excellent way to corrupt your database. > > As to where uncommitted transactions live, I am not sure. I'll let someone > else answer that. >
When a database page is modified during a transaction, the initial data is written to the rollback journal and the modified data is held in memory until COMMIT or the transaction memory cache is exceeded (see PRAGMA cache_size). If either of those happen, sqlite obtains an EXCLUSIVE lock on the database and starts writing the modified data (after making sure the rollback journal is properly synced to disk). At this point you have a partially committed transaction and the DB is not necessarily consistent (which is why it's done under an exclusive lock, and why deleting the rollback journal is a terrible idea as you said). In the case of COMMIT this is just a matter of I/O (syncing the DB and deleting the rollback journal) and should be fairly quick. But in the case of a cache spill, this partially committed state can be observed for much longer, depending on the size of the transaction. -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
