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.
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] 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
>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
>"database is locked" any more even if two threads writing at the same
>as mutex is disabled on core. Is it correct?
>Sent from: http://sqlite.1065341.n5.nabble.com/
>sqlite-users mailing list
sqlite-users mailing list