On Thu, Sep 28, 2017 at 1:16 PM, pisymbol . <pisym...@gmail.com> wrote:

>
>
> 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.
>
>
The follow-up to this is what is the purpose of full mutex mode and when
should it be used over no mutex mode?

I was using no mutex for a while until I thought full mutex might simplify
things a lot (pass one connection pointer around a few threads etc.). I
guess it would if I used auto-commit mode instead, right?

-aps
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to