> Thanks! I ran the example code and it seems like every UPDATE fails > with errors like the following: > > SqlStep Timeout on handle: 8 (rc = 6) > SqlStep tries on handle 8: 200 > BeginTrans Timeout/Error on handle: 8, Errorcode = 6 > Write Thread: DB is busy! tries = 142 handle = 8 > > Looking at the database contents it looks like none of the updates > were successful at all (though I didn't look extremely carefully). > > Are these errors normal?
A moderate number of timeout messages is "normal", they where also added to understand better how much load the sqlite db can handle using a multi thread application. However, this example was running with allmost no final error messages like "DB is busy! tries = 142", at least when I did it some month ago. The 142 tries means that the DB was busy for more than 1420 sec. I can't remeber that I achieved this, at least not with only two writer threads. You may reduce the number of writer threads by one using: #define NUM_WRITE_THREADS 1 If that still gives you an endless number of the above timeout messages then something is definetly wrong in your system. Please be aware also of: a) This exe is assumed to be the only instance running on a system. b) I'm still confident that the loop-redo style of the busy handling is one way to do it but the sqlite developers included a more clever approach using an notifier to handle this: http://www.sqlite.org/unlock_notify.html Havent tried this, though. c) Maybe a virus scanner is interfering here ? d) Maybe your system is slow ? :-) Marcus PS: Does anybody know how I can edit this example code ? I recently attempted to add a clear PD statement and also add some comments but when I try to edit I allways end up in the wiki index page... > > On Tue, Oct 27, 2009 at 12:55 AM, Marcus Grimm <mgr...@medcom-online.de> > wrote: >>> Another odd thing is that when I call sqlite3_reset on the prepared >>> statement, it also returns SQLITE_BUSY. Should I only reset the >>> statement when it has been executed successfully? >> >> one possible approach when getting SQLITE_BUSY is to >> retry the sqlite3_step call until it finally gets thru. >> >> note that sqlite3_reset just returns the same error >> code as the previous sqlite3_step call. >> >> attachments don't work on the list, you will need >> find another way to provide your example code. >> >> you may also take a look at >> http://www.sqlite.org/cvstrac/wiki?p=SampleCode >> for the busy handling. >> >> hth >> >> Marcus Grimm >> >>> >>> On Mon, Oct 26, 2009 at 2:40 PM, Chris T <citrus...@gmail.com> wrote: >>>> I'm new to sqlite (and sql in general, actually) and came across >>>> something puzzling. >>>> >>>> I wrote a test program statically linked with the amalgamated sqlite >>>> code. When I run a single instance, everything is fine. When I start >>>> a second instance in the same directory they both deadlock. Every >>>> call to sqlite3_step returns SQLITE_BUSY. >>>> >>>> The source code to my test program is attached. It was written in >>>> Visual Studio, so feel free to remove the reference to windows.h and >>>> change the calls to Sleep( ) if you don't use Windows. >>>> >>> _______________________________________________ >>> sqlite-users mailing list >>> 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 >> > _______________________________________________ > sqlite-users mailing list > 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
