This is exactly the expected behaviour of „journal mode“ with an insufficient timeout value in the reader connection (or none set at all). This is technically not an error condition, just a notification that the requested operation cannot be done „just right now“ and needs to be retried „later“.
Set or increase the timeout value on both connections to resolve the issue. Alternatively, switch into „WAL mode“. This will make the writer save it‘s changes in a Write Ahead Logfile without interfering with readers, who will still see the state of the DB at the time their transaction started. Von: Prajeesh Prakash [mailto:prajeeshprakash@elear.solutions] Gesendet: Montag, 03. Dezember 2018 08:39 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>; Hick Gunter <h...@scigames.at> Betreff: Re: [sqlite] [EXTERNAL] sqlite3_exec() 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<mailto: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<mailto: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<mailto: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<mailto:sqlite-users@mailinglists.sqlite.org> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick | Software Engineer | Scientific Games International GmbH<http://www.scigames.at> | 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
