Core bug with busy timeout (not working)
As per #155 and #1155 there still seems to be an issue with busy timeout not being respected.
The timeout option in new Database is not respected. For example, we set it to 10 seconds, and it sometimes immediately throws an error when the database is busy.
Hi, could you provide a reproduce-able example?
@JoshuaWise it's very hard to reproduce, but I'm having the same issue as commented here by another completely different user at https://github.com/WiseLibs/better-sqlite3/issues/155#issuecomment-1117609931
The issue happens way before 5 seconds.
Just out of curiosity, as there is nothing happening on the way down from setting the timeout on a new Database instance in JavaScript into the actual C function of sqlite: You are defining the timeout in milliseconds and you are not creating new instances of the database from several threads with different timeouts?
Correct, one single database instance, and setting it in milliseconds.
and it sometimes immediately throws an error when the database is busy.
That does not mean the timeout does not work. SQLite does not guarantee that the timeout is respected. In case of a deadlock it will immediately throw SQLITE_BUSY.
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 to the application instead of invoking the busy handler.
https://www.sqlite.org/c3ref/busy_handler.html
it's very hard to reproduce
Sounds a lot like a race condition that causes a deadlock.
Edit: in the linked issue you're saying
I'm using ava and it's using multiple processes/threads so that's probably culprit
But now you're saying
one single database instance
when asked if you're using
new instances of the database from several threads
Does that mean this issue is not related to your other comment? You have a single process, with a single thread and a single Database instance? In which case there could never be a timeout, because there is nothing to wait for.
better-sqlite3 doesn't do anything with the "busy timeout" except pass it directly to the underlying SQLite3 library. So this can't be an issue with better-sqlite3. I recommend posting on the SQLite forum: https://sqlite.org/forum/forum