On 26 Mar 2018, at 8:57am, Marco Bambini <ma...@sqlabs.net> wrote: > So it has nothing to do with which table/row the transaction is modifying?
Correct. SQLite does not have table-locking or row-locking. Any locks in a SQLite database lock the entire database. This is a fundamental aspect of SQLite and one of the reasons it's so fast and simple. > In your example connection 2 always returns with an error on COMMIT? Assuming I understand the documentation correctly ... If the commands are executed in the order I showed, then the second COMMIT will always return SQLITE_BUSY_SNAPSHOT instead of SQLITE_OKAY. > Seems like the improvement is only on when the error occurs and not on > concurrency or am I missing something? The BEGIN CONCURRENT command is inconvenient for most SQLite users and they should avoid it. It's an improvement for just a very few programs which depend on threads executing in predictable amounts of time. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
