On 14 Feb 2018, at 6:19am, Nick <haveagoodtime2...@gmail.com> wrote:
> Writing in thread 1 will no block SELECTs in thread 2 as I use WAL. But the
> INSERT within the transaction of thread 2 still returns SQLITE_BUSY.
> I think I have used sqlite3_busy_timeout() in right way and I find that
> sqliteDefaultBusyCallback() did not be called.
> Is it expected?
Yes. You have two threads writing to the same file. Naturally this cannot be
allowed, so one thread results in SQLITE_BUSY. The thread which gets that
resilt is the thread which tries to obtain a write lock second.
You should not be setting both a busy handler and a timeout. The idea is to
use one or the other. SQLite's own busy handler is very good at doin g the
right thing (it features exponential backoff) so most of the time you just set
a long timeout and don't bother writing your own busy handler.
sqlite-users mailing list