* Rowan Worth: > On 29 September 2015 at 03:47, Florian Weimer <fw at deneb.enyo.de> wrote: > >> Relatively rarely, while starting a transaction on a concurrently >> modified SQLite database in WAL mode, I get a SQLITE_BUSY_SNAPSHOT >> error for just-prepared "BEGIN IMMEDIATE" statement. >> > > BEGIN IMMEDIATE takes a RESERVED lock straight away, which for WAL mode > translates into 1) starting a read transaction and 2) upgrading to a write > transaction.
Thanks for the independent confirmation. It seems that I don't have to treat BEGIN IMMEDIATE in a special way after all. If a transaction fails with SQLITE_BUSY_SNAPSHOT and there are no busy statements which could cause persistent upgrade failures (which is true for a spurious BEGIN IMMEDIATE failure due to failed lock upgrade), I will retry the transaction and start it with BEGIN IMMEDIATE unconditionally (even if a lower isolation mode was requested originally). This will cover failed lock upgrades within the transaction, too.
