On 18 Jun 2019, at 4:19am, Keith Medcalf <kmedc...@dessus.com> wrote:
> See https://sqlite.org/lockingv3.html > for how transactions and locks work in journal_mode=delete|persist|truncate > (ie, not WAL). > There is a link on that page to how transactions work when WAL is in effect. > > Note that the default BEGIN [DEFERRED] [TRANSACTION] obtains a SHARED or > RESERVED lock only when the next statement is executed on that connection. > This means that an update (UPDATE/INSERT/DELETE) statement (on that > connection) may fail because it might not be able to acquire a lock (either > SHARED or RESERVED) that it requires. I understand about the RESERVED lock. I read the documentation. My surprise was at this, from further down the same page: " No EXCLUSIVE lock is acquired until either the memory cache fills up and must be spilled to disk or until the transaction commits. " and that's what I was asking about. I was surprised that by default SQLite waits until the last possible moment to gain an exclusive lock, risking failure after the program may have forgotten which changes were made. I suspect that a lot of software is using BEGIN when it should be using BEGIN EXCLUSIVE. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
