Hello Fin, It sounds like you're creating inserts faster than you can actually insert them in the DB so, things are backing up. In this case, it's the second worker that's backing up. I'd use a single worker thread that accepts DB requests from the other worker threads then queue jobs to the single DB worker. If one thread is being starved, that means the bottleneck is likely disk IO and not CPU. In that case, it's probably inefficient to use muliple writers to the DB.
It also means the single DB worker can use transactions more efficiently if it declares a transaction before working on the queue of insertion jobs. C Tuesday, April 22, 2008, 6:44:33 PM, you wrote: FS> I am using SQLite 3.5.7. This is a simplified example, but I have 2 FS> threads in the same process, each with their own connection, and cache FS> sharing disabled. FS> Thread A does: FS> while (some condtion) FS> BEGIN IMMEDIATE FS> do some INSERTs FS> COMMIT FS> Thread B occasionally wants to also do its own BEGIN IMMEDIATE...COMMIT FS> I found that thread A tends to hog the database: thread B often times FS> out when attempting to begin its transaction. I added a sleep of 2 FS> seconds at the bottom of thread A's loop, to give thread B a chance to FS> get in. That worked, but of course the throughput of thread A is FS> reduced as a result of the sleep calls, even when thread B doesn't FS> want to use the db. FS> Is there a better mechanism I should employ to ensure one writer FS> doesn't hog the database? FS> Thanks, FS> Dave FS> _______________________________________________ FS> sqlite-users mailing list FS> sqlite-users@sqlite.org FS> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- Best regards, Teg mailto:[EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
