On 8/9/19, Olivier Mascia <o...@integral.be> wrote: > Hello, > > I generally understand the locking states of SQLite well enough, I think. > Though this specific case below caught me off guard. I couldn't give an > immediate intelligible answer to my coworker. Nor could I find the answer > on the website, or I'm blind today. > > A connection holds a SHARED lock. It did start a DEFERRED transaction then > read something. Now it executes COMMIT. Will the lock be upgraded from > SHARED to EXCLUSIVE for the very short duration of the COMMIT (the > connection made no writing, as evidenced by its SHARED lock), or will this > specific case elude upgrading the lock and simply exit the transaction, > releasing the SHARED-lock to NO lock? Sounds logical, but is it true? In > other words, can I say that the lock upgrade to EXCLUSIVE at COMMIT time > only happens if the current lock state was RESERVED (and not simply SHARED)?
You are one of the rollback journaling modes, not WAL mode, right? Different rules apply for WAL mode. In rollback mode, the connection automatically promotes to EXCLUSIVE while committing the transaction. This is necessary to make sure no other connections are simultaneously reading the database, because it would not work for the committer to change content out from under the other readers. After the COMMIT, it falls back to unlocked. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
