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. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
