SQLITE_BUSY with concurrent transactions is expected behavior? #1198
Replies: 1 comment
-
Edit: before you read the below: are you using WAL? (
There is no such thing as an "internal queue", you were probably just lucky. Your transactions now do multiple reads/writes whereas before you only had transactions with a single read/write (every statement in SQLite is in an implicit transaction). It's just a matter of chance that this now comes up more frequently, because you are locking the db for longer.
Yes, see https://www.sqlite.org/rescode.html#busy (emphasis mine)
Edit: proof that a single write can trigger SQLITE_BUSY: Run this import Database from 'better-sqlite3'
const db = new Database('./foo.db');
// Won't SQLITE_BUSY with WAL
// db.pragma('journal_mode = WAL');
db.exec('CREATE TABLE IF NOT EXISTS foo (bar)');
const stmt = db.prepare('INSERT INTO foo (bar) VALUES (?)');
while(1) {
console.log('inserting...');
stmt.run(Math.random());
} |
Beta Was this translation helpful? Give feedback.
-
I'm running 2-3 concurrent processes reading and writing to the same database. With individual
INSERT
orUPDATE
I wasn't getting any issues, I guess the internal queue was handling the concurrency? But now I'm trying to wrap some of the database interactions in transaction functionsdb.transaction((data) => {..}
, but the transactions fail sometimes with SQLITE_BUSY error. Is this expected behavior and I have to wrap some retry logic around the transaction function, like this #155 (comment)?Does the issue #1067 apply to what I'm describing?
Beta Was this translation helpful? Give feedback.
All reactions