[sqlite version 3.28.0 (2019-04-16)] I am using sqlite3 in a multi-threaded application. Sqlite threading-mode is configured for multi-threading (compilation flag: SQLITE_THREADSAFE=2). In accordance to that each thread is using its own database connection. In addition, since the multiple connections can access the database simultaneously **and in order to avoid the ‘database is locked’ (error 5)** I implement a busy-handler callback and assign it to the connection using `sqlite3_busy_handler()` right after connection creation. Generally speaking, all is functioning well, however I did find that in some conditions my busy-handler is not being called. For example, in the next scenario: 1. Code begins transaction (“BEGIN TRANSACTION;”), 2. Code working with sqlite-statement (`sqlite3_prepare_v2()`, `sqlite3_bind_xxx()`), 3. Eventually when I call `sqlite3_step()` I receive the ‘database is locked’ error **without my busy-handler ever being called.** I know that in *sqlite* documentation it says: *"...The presence of a busy handler does not guarantee that it will be invoked when there is lock contention. If SQLite determines that invoking the busy handler could result in a deadlock, it will go ahead and return SQLITE_BUSY..."* However, my condition is a simple stand-alone application that does not share the database with other applications. For this reason, I cannot see why the above scenario will not call my call-back. I can only assume this is a bug in sqlite (?). **Workaround: "BEGIN IMMEDIATE TRANSACTION;"** I found that when using IMMEDIATE transaction my callback is being called and all seems to work, but I am not sure on how solid this solution is, and whether this problem could arise elsewhere. My question: Is there a way to configure sqlite to always call my busy-handler callback?