" It is not mentioned by the docs that your trace callback will be called encapsulated by a mutex - In other words: Are you sure that your trace callback is threadsafe ?"
Thanks for the suggestion Marcus. I have tried encapsulating the callback with a mutex to make it threadsafe. However, that yielded the same behavior. I appreciate your suggestion. -Eric -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Marcus Grimm Sent: Wednesday, September 05, 2012 3:44 PM To: General Discussion of SQLite Database Subject: EXTERNAL: Re: [sqlite] sqlite3_trace() threadsafe Am 2012-09-05 18:53, schrieb esum: > Thank you so much for all help. I really appreciate it. > > /"All the same, I'm guessing that > http://www.sqlite.org/src/info/39f763bfc0will fix your problem."/ > > I gave this new src code from the src tree a shot, but I seem to be > getting the same behavior. > > Interestingly though, I tried enforcing my own serialization of the > execution of the insert operations being called from the different > threads with a mutex such that the code that performs the inserts is > called sequentially from each thread, and this seemed to fix things. > I did not see any duplicate sql statements. (This is with the sqlite > src provided in the link compiled with the --enable-threadsafe and > --enable-cross-thread-connections which I assume sets the threading > mode to serialized). It is not mentioned by the docs that your trace callback will be called encapsulated by a mutex - In other words: Are you sure that your trace callback is threadsafe ? I can recall strange effects when doing "fprintf(stderr, ..." from different threads concurrently. Just a guess.. though. Marcus > > This leads me to believe that it has to do with contention/blocking > within sqlite as Simon explains: > > /"What I am guessing is happening is that sometimes sqlite3_trace() is > called, but is eventually held up because of access contention, a > situation where it can't go ahead because the database is locked. > Eventually the database becomes free again and this thread can go > ahead, at which point > _trace() gets called again."/ > > I also tried using the sqlite_profile( ) function, but this seems to > not keep the bound parameter values in the const char* sql statement > text, and this also replicated statements (I could tell because an > incorrect number of INSERTS were printed). > > I greatly appreciate any other thoughts on what my problem could be. > > > > -- > View this message in context: > > http://sqlite.1065341.n5.nabble.com/sqlite3-trace-threadsafe-tp64004p6 > 4030.html Sent from the SQLite mailing list archive at Nabble.com. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org<mailto:sqlite-users@sqlite.org> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org<mailto:sqlite-users@sqlite.org> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
