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
