Re: [sqlite] Dealing with SQLITE_BUSY

2018-02-22 Thread Igor Tandetnik
On 2/22/2018 5:54 AM, Nick wrote: I use sqlite3_open() to open two connections, and I have configured journal_mode=WAL, threadsafe=2. Connection 1 is doing: sqlite3_exec(db1, "BEGIN", 0, 0, &zErrMsg); sqlite3_exec(db1, "SELECT * FROM t1;", 0, 0, &zErrMsg); sqlite3_exec(db1, "INSERT INTO t1 VALUE

Re: [sqlite] Dealing with SQLITE_BUSY

2018-02-22 Thread Kees Nuyt
On Thu, 22 Feb 2018 14:36:07 +, Simon Slavin wrote: > On 22 Feb 2018, at 11:24am, Clemens Ladisch wrote: > >> Use "BEGIN IMMEDIATE" instead to tell the DB that you intend to write. > > Depending on how you want your locks to work, BEGIN EXCLUSIVE may work better. Yes, but note: "After a BE

Re: [sqlite] Dealing with SQLITE_BUSY

2018-02-22 Thread Keith Medcalf
Yes. See https://sqlite.org/lang_transaction.html From that page: "Transactions can be deferred, immediate, or exclusive. The default transaction behavior is deferred. Deferred means that no locks are acquired on the database until the database is first accessed. Thus with a deferred transact

Re: [sqlite] Dealing with SQLITE_BUSY

2018-02-22 Thread Simon Slavin
On 22 Feb 2018, at 11:24am, Clemens Ladisch wrote: > Use "BEGIN IMMEDIATE" instead to tell the DB that you intend to write. Depending on how you want your locks to work, BEGIN EXCLUSIVE may work better. Do remember when setting your timeout, that you have to set it in both connections. Simo

Re: [sqlite] Dealing with SQLITE_BUSY

2018-02-22 Thread Clemens Ladisch
Nick wrote: > I use sqlite3_open() to open two connections, and I have configured > journal_mode=WAL, threadsafe=2. > > Connection 1 is doing: > sqlite3_exec(db1, "BEGIN", 0, 0, &zErrMsg); > sqlite3_exec(db1, "SELECT * FROM t1;", 0, 0, &zErrMsg); > sqlite3_exec(db1, "INSERT INTO t1 VALUES(1, 1, \"a