On Jan 21, 2016, at 5:25 AM, Daniel Polski <daniel at agelektronik.se> wrote: > > Den 2016-01-21 kl. 11:30, skrev Simon Slavin: >> On 21 Jan 2016, at 9:44am, Daniel Polski <daniel at agelektronik.se> wrote: > >>> PRAGMA journal_mode = WAL; >> Once the database is in WAL mode that fact is saved in the file. > > We actually can't be sure that the database is already in WAL mode.
Why not? Didn?t you create it? If the user took it back out of WAL mode manually, presumably they know what they?re doing. If prior versions of your software didn?t use WAL, but migrated to it later, move the PRAGMA to your normal DB upgrade process. (I?m presuming your schema has to change occasionally to cope with new features, changed features, and removed obsolete features. Set the PRAGMA in that process.) >> PRAGMA busy_timeout = 10 * 1000; >> >> then just take the first _LOCKED or _BUSY as a failure. > > We already tried that, but that doesn't seem to have any effect. If it fails > locked or busy the timeout doesn't seem to make any difference. (This may as > well be a quirks of PHP on top of it) That means someone is holding the database locked, such as with an unclosed BEGIN TRANSACTION call. This *is* the information you?re looking for. Switching from the built-in retry logic to custom logic doesn?t help. You have to fix the process that holds the lock too long. With SQLite?s lack of row-level locking, your usage pattern should distill to ?get in, get done, and get out, ASAP.? Many fine-grained queries are better than heroic multi-statement queries that change the world.
