?Hello all, I have a multithreaded server that may perform intense database actions (both reads and writes) concurrently from different threads against two database connection (sqlite3* objects) to the same database file. The database connections are in shared-cache mode and I have implemented the unlock notification mechanism (sqlite3_unlock_notify()) in order to facilitate table-level locking according to instructions given here: https://www.sqlite.org/unlock_notify.html. I also use sqlite_busy_timeout() to set an internal retry mechanism with a reasonably large timeout value in order to avoid SQLITE_BUSY errors. ??
While in rudimentary tests the whole mechanism seems to work as expected, in normal server operation under heavy load some statements (different ones each time) seem to return SQLITE_BUSY immediately, which seems to indicate that busy_timeout() dos not work in some cases. And this does not change even if I set the busy timeout to a very large value, e.g. 0x7FFFFFFF ?, and calling PRAGMA busy_timeout reports the expected value? . Also, it doesn't seem to have a difference if the database is in WAL or DELETE mode. What may I be doing wrong? Or is there something regarding busy_timeout() I have missed? A scenario where it is bypassed? Unfortunately this behaviour appears only under heavy load in customer sites and is very hard to reproduce and debug. SQLite version is 3.8.10.1, OS is Win7 x64 and the server is compiled in 32-bit and SQLite is dynamically linked via separate library (sqlite3.dll), locking_mode is NORMAL, synchronous is FULL and threading mode is SERIALIZED. Thank you in advance. -- Constantine.
