Kira Backes wrote: > Our code base does not use transactions at all When you do not use explicit transactions, SQLite will automatically create implicit transactions.
<https://www.sqlite.org/lang_transaction.html> says: | An implicit transaction (a transaction that is started automatically, | not a transaction started by BEGIN) is committed automatically when | the last active statement finishes. A statement finishes when its | prepared statement is reset or finalized. > we're supposed to be able to share a connection between threads as > long as we do not read/write into the same table at the same time One connection implies one transaction. So if two statements happen to be active at the same time in two threads, they will share a transaction, and might keep the transaction active longer than the other thread expects. See <https://www.sqlite.org/isolation.html>. > After thinking a very long time about this I found the reason: You > absolutely can not share a WAL connection between threads or risk > SQLITE_BUSY events. This is not really related to threads; the same can happen when a single thread tries to write in a formerly read-only transaction. > This is not a theoretical case, this can happen *VERY* easily and as > far as I can tell this is not documented anywhere <https://www.sqlite.org/rescode.html#busy_snapshot> It is strongly recommended to use a separate connection per thread. Regards, Clemens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
