Strange error stack trace: both "SQL error" and "journal file not found" about wa-sqlite HOT 7 CLOSED

I only mentioned code snippets that I feel important to wa-sqlite. You are free to check out the full code here: thanhnguyen2187/crypta#28.

from wa-sqlite.

I agree that you're likely overlapping calls into wa-sqlite. That's on you to debug, I'm afraid. You might try setting a breakpoint on each API call you make to check the state of your application.

from wa-sqlite.

You could also try using the debug build. You would need to follow the build instructions from the README.md and make debug, which writes the WASM artifacts to debug/ (instead of dist/). That might assert sooner and/or give you more actionable error messages.

from wa-sqlite.

Thanks a lot for the suggestion! I thought of another way to mitigate the issue and was going to work on it soon, but I'll also try the debugging WASM and let you know if there is anything relevant.

Another question: theoretically, wa-sqlite (and IDBBatchAtomicVFS) should be able handle concurrent reads, and mixed reading writing, right? I rechecked my code and there were two cases:

• One read, one write
• Two reads

from wa-sqlite.

theoretically, wa-sqlite (and IDBatchAtomicVFS) should be able handle concurrent reads, and mixed reading writing, right?

If you mean on the same instantiated WASM module, no. You cannot have multiple calls to SQLite in flight simultaneously.

If you mean concurrent transactions on the same database from different instantiated WASM modules (typically also from different JavaScript contexts), whether you can overlap transactions depends on locking support in the VFS you use. See this FAQ item for details.

from wa-sqlite.

If you mean on the same instantiated WASM module, no. You cannot have multiple calls to SQLite in flight simultaneously.

I see. Everything makes sense now. I'll elaborate the case for posterity.

There is this piece in my code:

export async function createSQLiteAPI(): Promise<SQLiteAPI> {
  // @ts-ignore
  const module = await SQLiteESMFactory()
  const sqlite3 = SQLite.Factory(module)
  const vfs = new IDBBatchAtomicVFS()
  // const vfs = new OriginPrivateFileSystemVFS()
  sqlite3.vfs_register(vfs, true)
  return sqlite3
}

Where the returned result is used in another object. That object is utilized in two different places simultaneously (as per the first comment). In the end, it raises some seemingly unrelated stack traces.

from wa-sqlite.

What if you set up a pool of connections within a shared worker, and then accessed each of those connections using different locks? Or a hierarchical locking strategy?

from wa-sqlite.