On 28 Feb 2017, at 6:39pm, Matthew Ceroni <matthewcer...@gmail.com> wrote:
> After a bit of reading and troubleshooting I stumbled across the > busy_timeout option (which defaults to 0). Prior to execute the create > table statement I set PRAGMA busy_timeout=1000 (1 s) and the writes always > succeeded. You need to set the busy timeout at every connection to the database, including those which only read and never write. It’s common to see it done immediately after the sqlite3_open() command. It is not stored in the database and new connections to the database do not know what it was set to before. If that doesn’t fix things, as a diagnostic measure, try setting busy_timeout to 30 seconds instead of just 1 second. Learning whether this does or does not fix the problem will tell you a lot about what’s going on. Are you using WAL mode ? If not, you should try it. Locking works differently in WAL files, as described in <https://www.sqlite.org/wal.html> > So since busy_timeout defaults to 0, all write attempts if a lock can't be > obtained will return SQLITE_BUSY immediately. Where does the PENDING lock > come into play here? I thought the PENDING was meant to be an intermediary > step before EXCLUSIVE. Does the busy_timeout impact the writers attempt to > obtain PENDING? Or does the busy_timeout trigger after X amount of ms > between obtaining PENDING and trying to move to EXCLUSIVE? There are two kinds of locks: shared and exclusive. A pending lock means you have shared, not exclusive, but that you want exclusive. timeout applies when obtaining both shared and exclusive locks. Actually, hold on, I’m not sure about this. Better to try what I wrote already then get an expert to explain things. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
