SQLITE_OPEN_FULLMUTEX ensures that EACH CONNECTION is SERIALLY ENTRANT into the Sqlite3 library code (ie, that two threads cannot make a call into the library on different threads AT THE SAME TIME, or put another way that only ONE THREAD at a time on EACH CONNECTION may make a call into the library). The Sqlite3 database engine code is only MULTIPLY ENTRANT on separate connections, but is required to be SERIALLY ENTRANT with respect to a (as in one) particular connection. The default is serialized, or OPEN_FULLMUTEX, in order to prevent you from exploding something due to careless use of a connection in multiple threads.
Since transaction locking is handled at the CONNECTION level, if you use the same connection simultaneously from multiple threads they all share THE SAME ONE SINGLE transaction context. In order to get an SQLITE_LOCKED response there must be more than one connection to the database, and one of those connections must be locking the database, in order for THE OTHER CONNECTION to get an SQLITE_LOCKED response. There is no difference between using a SINGLE CONNECTION in a SINGLE THREAD or in MULTIPLE THREADS so long so long as you abide by the SINGLE ENTRANCE requirement. --- 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 Hick Gunter >Sent: Wednesday, 28 November, 2018 00:54 >To: 'SQLite mailing list' >Subject: Re: [sqlite] [EXTERNAL] SQLITE_OPEN_FULLMUTEX > >Using SQLITE_OPEN_FULLMUTEX puts SQLite into serialized mode. This >means that mutltiple threads can share a single connection but will >block until the mutex is freed because the thread currently holding >the mutex has left the SQLite code. Blocked threads will only >experience a time delay (concurrency is reduced). > >This is distinct from the SQLITE_LOCKED, which means that there is a >(logical) conflict iin the same DB connection, e.g. attempting to >drop a table in one thread while reading from the same table in >another thread. > >-----Ursprüngliche Nachricht----- >Von: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] Im Auftrag von Prajeesh Prakash >Gesendet: Mittwoch, 28. November 2018 08:33 >An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> >Betreff: [EXTERNAL] [sqlite] SQLITE_OPEN_FULLMUTEX > >Hi Members, > >I enabled the SQLITE_OPEN_FULLMUTEX in that case if one thread is >trying to write in to the DB and other thread is trying to read from >the DB (Same connection). In that case will it cause any >SQLITE_LOCKED error. In some of the forum i found that if we enable >the SQLITE_OPEN_FULLMUTEX the sqlite handle ( sqlite3 * handle) >contains the mutex filed so when the sqlite library is invoking that >API will wait for the mutex to get open. > > > >Thank you >_______________________________________________ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > >___________________________________________ > Gunter Hick | Software Engineer | Scientific Games International >GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: >0430013 | (O) +43 1 80100 - 0 > >May be privileged. May be confidential. Please delete if not the >addressee. >_______________________________________________ >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
