THREADSAFE has NOTHING to do with transactions.  Repeat, there is no value to 
which you can set the THREADSAFE constant which has any effect whatsoever on 

Transactions are commenced ON A CONNECTION with either (a) implicitly as 
required if you do not do it yourself (known as "magical mystery mode" or "hope 
and pray" mode) or (b) when one of the BEGIN transaction statements is PREPARED 
and STEPped to completion on a CONNECTION.  That connection and all threads and 
statements associated with or prepared from that CONNECTION are now part of the 
transaction on that CONNECTION.  The transaction is ended when the "last active 
statement" is reset on the connection (for transactions that are implicitly 
commenced by sqlite3 and not explicitly by you) or when you prepare and step to 
completion a COMMIT or ROLLBACK statement on the CONNECTION.

Nothing in the above paragraph is affected by the THREADSAFE setting, the phase 
of the moon, or the depth of the snow on the ground.

The THREADSAFE setting determines the "sloppiness" of the programming style you 
use to interact with the sqlite3 library.  

THREADSAFE=0 means that your slopiness does not matter because the program is 
SINGLE-THREADED and you will make calls only from a SINGLE (MAIN) thread.

THREADSAFE=1 means that you are likely sloppy and that sqlite3 itself will 
ensure that you do not, through your slopiness, cause AHTBL.

THREADSAFE=2 means that you are extra careful to make sure that you NEVER EVER 
have the possibility of multiple entrances to the sqlite3 library on the same 
CONNECTION (which would require multiple threads, or multiple fibres, or just 
an OS that plays dipsy poodle (such as Windows)).  In case you are not 
sufficiently careful in your design and programming, sqlite3 WILL NOT take 
precautions to prevent you from killing yourself, your data, your application, 
or your database file (in other words, sqlite3 will NOT prevent AHTBL if you 
happen to be in actuality sloppy in your design or implementation)

Nothing in the above 4 paragraphs is affected by the TRANSACTION state of a 
CONNECTION, the phase of the moon, or the depth of the snow on the ground.

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-
>] On Behalf Of Nick
>Sent: Tuesday, 13 February, 2018 02:14
>Subject: Re: [sqlite] Question about threadsafe
>>> is it OK to use "threadsafe=2 and
>>> 2 connections" in my apps if the 2 threads may write at the same
>So I think "threadsafe=2 + more than 1 connection + busy_handler" is
>a good
>way to use.
>Another possible way is "threadsafe=1 and share 1 connection", but if
>1 begins a transaction, then the SQL of thread 2 will also be
>within the transaction I guess. That may cause some unpredictable
>BTW, if I use "threadsafe=0 and more than 1 connection", there will
>not be
>"database is locked" any more even if two threads writing at the same
>as mutex is disabled on core. Is it correct?
>Sent from:
>sqlite-users mailing list

sqlite-users mailing list

Reply via email to