On 4 Sep 2012, at 7:14pm, esum <eric.b....@lmco.com> wrote:

> I am getting odd results when I do a simple test such as doing a couple of
> inserts to different tables from 4 threads.  Some sql statements appear to
> be printed twice or more when they should only be printed once.  The sql
> statements that are replicated vary from test to test, and I am lead to
> believe that there may be some race condition.  Is sqlite3_trace ()
> threadsafe?

As far as we know sqlite3_trace() is 100% threadsafe unless you have chosen 
options explained in

http://www.sqlite.org/threadsafe.html

which defeat thread safety for other parts of SQLite.

> Is there a reason that the same sql statement is being passed
> twice to the callback function when it is really only executed once?  As a
> note, the database itself appears to be perfectly fine with everything in
> tact and as expected.

Nice analysis.  Thanks for posting enough that we understand your setup and can 
help you.

I think you're being caught by something you didn't notice in the documentation:

<http://www.sqlite.org/c3ref/profile.html>

"The sqlite3_trace() callback is invoked with a UTF-8 rendering of the SQL 
statement text as the statement first begins executing. Additional 
sqlite3_trace() callbacks might occur as each triggered subprogram is entered."

Notice the 'might'.  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.  You might be able to play with your 
value for sqlite3_busy_timeout() and prove or disprove this.

Whether I guessed right or not, the 'additional' suggests that there's no 
problem with your code, and you're just seeing some inner workings of SQLite 
you hadn't expected.

Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to