Transactions are an attribute of the connection and the threads are irrelevant.
So once you BEGIN a transaction on a connection, that connection is inside a transaction for any and all threads that may happen to use that connection. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of pisymbol . >Sent: Thursday, 28 September, 2017 11:16 >To: SQLite mailing list >Subject: Re: [sqlite] FULLMUTEX and exclusive transactions between >threads > >On Thu, Sep 28, 2017 at 11:55 AM, Simon Slavin <slav...@bigfraud.org> >wrote: > >> >> >> 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 >> > >So even with full mutex, if I have thread 1 issue a "BEGIN" and it >starts >processing, and another thread 2 issues a "BEGIN" somewhere in >between >that, the other thread will just flat out fail because a transaction >has >already started for thread 1. Is that correct? > >MAN, the doc is very unclear about this. > > >> > 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. >> > >Before I answer that, can you please confirm the above? > >-aps >_______________________________________________ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
