-
Notifications
You must be signed in to change notification settings - Fork 7
Description
The README claims that (emphasis mine):
By setting the SQLWFlag::NoTransactions, no transactions are opened and closed. This also means no thread is created for managing these transactions.
A reader might think that with this flag, database transactions are disabled entirely, but that is not the case:
No reads or writes occur except within a transaction. Any command that accesses the database (basically, any SQL command, except a few PRAGMA statements) will automatically start a transaction if one is not already in effect. Automatically started transactions are committed when the last SQL statement finishes.
In effect, the NoTransactions flag doesn't disable SQLite transactions, but it does make it so that each SQLite transaction is shorter in duration (and happens entirely on the calling thread), rather than artificially making it so that transactions remain open and holding on to their resources for up to a second (to be picked up by the commit thread).
This is, of course, a significant improvement in the "occasional reads and writes" usage scenario, but it doesn't quite match the description. Closer might be:
The SQLiteWriter NoTransactions mode corresponds to SQLite's auto-commit mode: a database transaction is started and committed for every statement, rather than committing every second as described above.