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.
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- >boun...@mailinglists.sqlite.org] On Behalf Of Nick >Sent: Tuesday, 13 February, 2018 02:14 >To: sqlite-users@mailinglists.sqlite.org >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 >time? > >>Yes. > >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 >thread >1 begins a transaction, then the SQL of thread 2 will also be >executed >within the transaction I guess. That may cause some unpredictable >problems. > >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 >time, >as mutex is disabled on core. Is it correct? > > > >-- >Sent from: http://sqlite.1065341.n5.nabble.com/ >_______________________________________________ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
