FULLMUTEX and exclusive transactions between threads

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

FULLMUTEX and exclusive transactions between threads

pisymbol .
Hello:

I have an application that makes heavy use of sqlite3 and during load
testing I very, very rarely  (read: it has only happened once so far)
occasionally see the following error message:

"BEGIN EXCLUSIVE error: cannot start a transaction within a transaction"

I understand this error message and usually I cough it up to some
connection issuing a "BEGIN;" statement after a previous transaction has
already started and not been finalized by either a "COMMIT;" or "ROLLBACK;"
statement respectively.

However, if an application shares a single connection to an sqlite3
database and that connection was opened up with SQLITE3_OPEN_FULLMUTEX,
(note the complete flags were
"SQLITE_OPEN_CREATE|SQLITE_OPEN_READWRITE|SQLITE_OPEN_PRIVATECACHE") aren't
all queries in effect serialized? And as such this error condition above
can never occur between different threads holding the same connection that
was opened with the full mutex flag?

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, and life goes on.

I did read this thread:

http://sqlite.1065341.n5.nabble.com/Multiple-reads-and-writes-to-a-single-DB-connection-from-multiple-threads-td75972.html

And based on that I believe I'm right but I want to verify my understanding
of this flag. Of course, now I need to understand how the above even
happened if everything above holds true (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.).

Thanks!

-aps
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Simon Slavin-3


On 28 Sep 2017, at 3:31pm, pisymbol . <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Igor Korot
Hi, Simon,

On Thu, Sep 28, 2017 at 11:55 AM, Simon Slavin <[hidden email]> wrote:

>
>
> On 28 Sep 2017, at 3:31pm, pisymbol . <[hidden email]> 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.

But the lock will be released on _finalize(), right?

Thank you.

>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Simon Slavin-3


On 28 Sep 2017, at 5:00pm, Igor Korot <[hidden email]> wrote:

> But the lock will be released on _finalize(), right?

Yes.  Or on _reset().  Nevertheless, the transaction lasts until that point, so the use of BEGIN, or the start of another SQLite one-statement transaction cannot happen until then and will yield an error result.

At least I think so.  Happy to be corrected by anyone who actually does multi-thread programming.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

pisymbol .
In reply to this post by Simon Slavin-3
On Thu, Sep 28, 2017 at 11:55 AM, Simon Slavin <[hidden email]> wrote:

>
>
> On 28 Sep 2017, at 3:31pm, pisymbol . <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

pisymbol .
On Thu, Sep 28, 2017 at 1:16 PM, pisymbol . <[hidden email]> wrote:

>
>
> On Thu, Sep 28, 2017 at 11:55 AM, Simon Slavin <[hidden email]>
> wrote:
>
>>
>>
>> On 28 Sep 2017, at 3:31pm, pisymbol . <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Simon Slavin-3
In reply to this post by pisymbol .


On 28 Sep 2017, at 6:16pm, pisymbol . <[hidden email]> wrote:

> 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?

Correct.  Connections are the way into SQLite.  Because both threads are using the same connection, SQLite thinks they’re part of the same effort.  So as far as SQLite is concerned, the two threads are supplying SQL commands for the same transaction.

As far as SQLite is concerned, you have one connection which executed BEGIN and then executed BEGIN again without having ended the first transaction.

On 28 Sep 2017, at 6:23pm, pisymbol . <[hidden email]> wrote:

> The follow-up to this is what is the purpose of full mutex mode and when
> should it be used over no mutex mode?

The mutex is useful when SQLite can tell that your commands are actually part of two separate efforts.  i.e. when you’re using two different connections.


Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

pisymbol .
On Thu, Sep 28, 2017 at 1:30 PM, Simon Slavin <[hidden email]> wrote:

>
>
> On 28 Sep 2017, at 6:16pm, pisymbol . <[hidden email]> wrote:
>
> > 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?
>
> Correct.  Connections are the way into SQLite.  Because both threads are
> using the same connection, SQLite thinks they’re part of the same effort.
> So as far as SQLite is concerned, the two threads are supplying SQL
> commands for the same transaction.
>
> As far as SQLite is concerned, you have one connection which executed
> BEGIN and then executed BEGIN again without having ended the first
> transaction.
>

Then I understand why my error occurred. This is a bummer. I will have to
readjust.


>
> On 28 Sep 2017, at 6:23pm, pisymbol . <[hidden email]> wrote:
>
> > The follow-up to this is what is the purpose of full mutex mode and when
> > should it be used over no mutex mode?
>
> The mutex is useful when SQLite can tell that your commands are actually
> part of two separate efforts.  i.e. when you’re using two different
> connections.
>
>
If you are using two different connections, then they both have to be
opened with full mutex and then SQLite will serial accordingly. Is that
right?

-aps
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Keith Medcalf
In reply to this post by pisymbol .

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-
>[hidden email]] 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 <[hidden email]>
>wrote:
>
>>
>>
>> On 28 Sep 2017, at 3:31pm, pisymbol . <[hidden email]> 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
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Simon Slavin-3
In reply to this post by pisymbol .


On 28 Sep 2017, at 6:41pm, pisymbol . <[hidden email]> wrote:

> If you are using two different connections, then they both have to be
> opened with full mutex and then SQLite will serial accordingly. Is that
> right?

You’re right at the edge of my competency but I believe that is correct.  My understanding is that both connections have to be told to respect the mutex.  However this should be the default setting on _open(), since SQLite tends to have defaults which give the safest results.

The closest I know in the documentation is

<https://sqlite.org/c3ref/open.html>

"If the SQLITE_OPEN_NOMUTEX flag is set, then the database connection opens in the multi-thread threading mode as long as the single-thread mode has not been set at compile-time or start-time. If the SQLITE_OPEN_FULLMUTEX flag is set then the database connection opens in the serialized threading mode unless single-thread was previously selected at compile-time or start-time."

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Keith Medcalf
In reply to this post by Simon Slavin-3
>> The follow-up to this is what is the purpose of full mutex mode and when
>> should it be used over no mutex mode?

>The mutex is useful when SQLite can tell that your commands are
>actually part of two separate efforts.  i.e. when you’re using two
>different connections.

The mutex is used to prevent multiple concurrent entry (ie, calling an sqlite3_* function) using the same connection from multiple threads.  (ie, serialization).  It does not provide isolation of any sort.  THat is to say that you can prepare a statement on a connection and then step it on another and finzalize on a third.  What you cannot do (and what serialization prevents) is have two threads make calls at the same time on the same connection object.

You would use no mutex mode if YOUR CODE ensures that there will never be an attempt at concurrent entry on a connection across threads.


---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>
>
>Simon.
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Simon Slavin-3


On 28 Sep 2017, at 6:57pm, Keith Medcalf <[hidden email]> wrote:

> The mutex is used to prevent multiple concurrent entry (ie, calling an sqlite3_* function) using the same connection from multiple threads.  (ie, serialization).  It does not provide isolation of any sort. THat is to say that you can prepare a statement on a connection and then step it on another and finzalize on a third.  What you cannot do (and what serialization prevents) is have two threads make calls at the same time on the same connection object.

Ah, that makes more sense.  Believe Keith about this, not what I posted earlier.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

pisymbol .
On Thu, Sep 28, 2017 at 2:10 PM, Simon Slavin <[hidden email]> wrote:

>
>
> On 28 Sep 2017, at 6:57pm, Keith Medcalf <[hidden email]> wrote:
>
> > The mutex is used to prevent multiple concurrent entry (ie, calling an
> sqlite3_* function) using the same connection from multiple threads.  (ie,
> serialization).  It does not provide isolation of any sort. THat is to say
> that you can prepare a statement on a connection and then step it on
> another and finzalize on a third.  What you cannot do (and what
> serialization prevents) is have two threads make calls at the same time on
> the same connection object.
>

So you can still have issues with thread 1 issuing a "BEGIN" and then
thread 2 issuing another "BEGIN" before thread 1 finalizes the transaction
causing failure. Correct?

-aps
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Simon Slavin-3


On 28 Sep 2017, at 8:01pm, pisymbol . <[hidden email]> wrote:

> So you can still have issues with thread 1 issuing a "BEGIN" and then
> thread 2 issuing another "BEGIN" before thread 1 finalizes the transaction
> causing failure. Correct?

Don’t know.  Hope someone else does.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Igor Korot
Not if you use connection-per-thread model.

On Thu, Sep 28, 2017 at 3:07 PM, Simon Slavin <[hidden email]> wrote:

>
>
> On 28 Sep 2017, at 8:01pm, pisymbol . <[hidden email]> wrote:
>
>> So you can still have issues with thread 1 issuing a "BEGIN" and then
>> thread 2 issuing another "BEGIN" before thread 1 finalizes the transaction
>> causing failure. Correct?
>
> Don’t know.  Hope someone else does.
>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

pisymbol .
On Thu, Sep 28, 2017 at 3:11 PM, Igor Korot <[hidden email]> wrote:

> Not if you use connection-per-thread model.
>
>
Yes, right. That I understand and am in the midst of doing that right now.

-aps
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Jens Alfke-2
In reply to this post by pisymbol .


> On Sep 28, 2017, at 10:41 AM, pisymbol . <[hidden email]> wrote:
>
> If you are using two different connections, then they both have to be
> opened with full mutex and then SQLite will serial accordingly. Is that
> right?

SQLite connections are completely independent of each other; they share no data* or file descriptors. There are no thread-safety issues between SQLite calls made on different connections. If you open multiple connections, you don’t have to use any of SQLite’s compile-time or runtime mutex support ... as long as those connections are used on separate threads. (I.e. no two threads ever make a SQLite call with the same connection at the same time.)

—Jens

* unless you do something unusual like using shared-cache mode
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

Keith Medcalf
In reply to this post by pisymbol .

If they are both using the same connection, yes.  Transaction state is an attribute of the connection, not the statement or thread.

---
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-
>[hidden email]] On Behalf Of pisymbol .
>Sent: Thursday, 28 September, 2017 13:02
>To: SQLite mailing list
>Subject: Re: [sqlite] FULLMUTEX and exclusive transactions between
>threads
>
>On Thu, Sep 28, 2017 at 2:10 PM, Simon Slavin <[hidden email]>
>wrote:
>
>>
>>
>> On 28 Sep 2017, at 6:57pm, Keith Medcalf <[hidden email]>
>wrote:
>>
>> > The mutex is used to prevent multiple concurrent entry (ie,
>calling an
>> sqlite3_* function) using the same connection from multiple
>threads.  (ie,
>> serialization).  It does not provide isolation of any sort. THat is
>to say
>> that you can prepare a statement on a connection and then step it
>on
>> another and finzalize on a third.  What you cannot do (and what
>> serialization prevents) is have two threads make calls at the same
>time on
>> the same connection object.
>>
>
>So you can still have issues with thread 1 issuing a "BEGIN" and then
>thread 2 issuing another "BEGIN" before thread 1 finalizes the
>transaction
>causing failure. Correct?
>
>-aps
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: FULLMUTEX and exclusive transactions between threads

pisymbol .
On Thu, Sep 28, 2017 at 9:18 PM, Keith Medcalf <[hidden email]> wrote:

>
> If they are both using the same connection, yes.  Transaction state is an
> attribute of the connection, not the statement or thread.
>
>
Thanks everybody for the explanations! I have moved to a connection per
thread model since to avoid this issue entirely.

-aps
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users