Hi Simon and Roger, Simon Slavin wrote: > On 15 Aug 2009, at 9:58am, Sebastian Arcus wrote: > > >> I've just noticed another interesting thing. A read operation after a >> write on same table (like a SELECT statement after an INSERT) works >> perfectly fine - instantly. Which is bizarre, as I would have >> expected a >> write to keep a much longer lock on the table then a read. So it's >> only >> writes after reads that causes the lock. >> > > Would it be possible to put the SQL commands into a text file, use the > command-line utility to execute the text file, and time how long it > takes ? > > Since the command-line utility uses the bare sqlite function library > and very little extra code, this would tell you whether the delay is > being caused by the SQLite library on down, or some level above the > SQLite library. > > Just to thank you both for your suggestions and to let you know the problem is solved. I've tried your suggestion Simon and everything worked fine through the SQLite command line directly. So I proceeded to strip down all my code line by line and function by function until I found the problem. It was all my doing. A dodgy function return was cutting off my code - and a statement object (container for SQL in the mozStorage implementation) which I was under the impression that was being finalized/reset (to be re-used in the second SQL query) was not. Actually the Mozilla people do warn that any statement object needs to be reset (or finalized, which includes a reset) before it can be re-used. The statement reset code was all there - it was just never executed. Thus it seems that it took about 10 seconds for the statement object to be reset by default - without specific instruction. Entirely my fault.
Thanks for all the input. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
