Thank you for the response. Using 1 connection per thread will allow the reader thread to read all of the "old" records (and none of the "new" records). Then, the writer can add the "new" records. A subsequent read will return both "old " and "new" records.
If this is the case the reader thread on connection 1 will get a SQLITE_BUSY if the writer thread is writing on DB using connection 2. Because when i tested the scenario (its Doesn't matter which table i am writing/reading) like writing and reading using 2 different connection i am getting BUSY error status (Writing and reading same table, Writing and reading two different table) . > > On December 3, 2018 at 12:56 PM Hick Gunter <h...@scigames.at> wrote: > > An SQLite connection is not a unix standard file handle. By using only > one connection for two concurrent tasks, you are getting interference from > operations which would usually be isolated from each other. Sharing a > connection between threads is there because SQlite also runs on embedded > systems that may have low limits on the number of file handles a process may > open simultaneously. > > Using 1 connection per thread will allow the reader thread to read all of > the "old" records (and none of the "new" records). Then, the writer can add > the "new" records. A subsequent read will return both "old " and "new" > records. > > -----Ursprüngliche Nachricht----- > Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] > Im Auftrag von Prajeesh Prakash > Gesendet: Samstag, 01. Dezember 2018 14:51 > An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> > Betreff: [EXTERNAL] [sqlite] sqlite3_exec() > > Hi Team, > Is this sqlite3_exec() function is a blocking call in the case of > writing.I have two thread one is for reading and other is for writing the DB. > Both thread have the same DB connection(Of course i am in FULLMUTEX mode and > sqlite point of few there is no multiple thread every thing is serialized). > Reader thread starts first and continuously reading 500 records from a table > (I kept the sqlite3_exec() function call inside a loop for continues reading > ie, on one iteration it will print 500 records and it is printing > successfully using callback function). After 1sec of delay writer thread > starts its execution and tries to write 500 records into the same > table,Because of the small loop iteration gap in the reader thread the writer > will get a chance to update the table hence my reader thread is blocked may > be the mutex on the sqlite3* is acquired by the writer thread. After around > 45 sec reader start its operation but one thing i observed is that the newly > added entry is not printing > instead of that old data is printing so i increased the reader thread > looping iteration. After few iteration is over the newly added records also > printing along with the old data. Why this delay is happening? (even though > the writer thread is not coming out from the sqlite3_exec which i used to > write the data but after a few sec its came out at that time onward i am > getting the updated data). Along with the INSERT sql statement i am not using > any BEGIN TRANSACTION and COMMIT. > Please give a suggestion for this. > > 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
