On 28 Sep 2017, at 3:31pm, pisymbol . <pisym...@gmail.com> wrote:
> Specificially, if thread 1 and 2 both have a handle to sqlite3 with full > mutex, then both could start a transaction simultaneously, one will win the > other will wait, [snip] By "serialised" the documentation means that no two SQL commands will be allowed to take place at the same time. But SQL can’t separate your two different threads into two different sources of commands. As far as its concerned, anything which uses your single connection is part fo the same command-stream. So if one part of your program executes BEGIN then everything from any source from then onwards is part of the same transaction until some part of your program executes "COMMIT". If you want your program to execute two different transactions at the same time (and handle the bookkeeping necessary to make one wait for the other to complete) you must use two different connections. And if you have three independent parts of your program which may all depend on transaction isolation, you need three connections > I can't find where a single thread > of execution could issue "BEGIN" twice in my code though I did find that I > was calling sqlite3_lastrow_insert() twice in a row by accident but I don't > know how that could cause the above.) Do you use _prepare(), _step(), _finalize() for a multi-row SELECT anywhere ? What probably happened is that one thread executed _step() for a multi-row SELECT. That means it is in the middle of a SELECT command, so it wouldn’t have released its lock on the database. Only when a _step() command has reached the end of the rows and returned SQLITE_DONE (or an error) is the SQL command over, at which point SQLite can end the transaction. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
