Weirdo response, but ... make sure you have HAVE_USLEEP defined. We kept seeing something similar, and kept looking at the code for sqliteDefaultBusyCallback(), and the code looked right, but the problem remained, until we eventually started questioning every assumption. At which point we found that we needed to add -DHAVE_USLEEP=1 somewhere.
Also, you should note your platform. Anyhow, another solution would naturally be to use a mutex to prevent multiple writers from getting in. Depending on your app's structure, this can be pretty annoying to add on top... -scott On Tue, Apr 22, 2008 at 3:44 PM, Fin Springs <[EMAIL PROTECTED]> wrote: > I am using SQLite 3.5.7. This is a simplified example, but I have 2 > threads in the same process, each with their own connection, and cache > sharing disabled. > > Thread A does: > > while (some condtion) > BEGIN IMMEDIATE > do some INSERTs > COMMIT > > Thread B occasionally wants to also do its own BEGIN IMMEDIATE...COMMIT > > I found that thread A tends to hog the database: thread B often times > out when attempting to begin its transaction. I added a sleep of 2 > seconds at the bottom of thread A's loop, to give thread B a chance to > get in. That worked, but of course the throughput of thread A is > reduced as a result of the sleep calls, even when thread B doesn't > want to use the db. > > Is there a better mechanism I should employ to ensure one writer > doesn't hog the database? > > Thanks, > Dave > > _______________________________________________ > 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
