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

Reply via email to