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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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