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.
Have thread B let thead A know that it wants in by using some synchronization primitive. E.g on Windows I'd use a manual reset event. Thread A waits on the event at the top of the loop. The event is set (signalled) most of the time, so the wait doesn't block. But when thread B wants to write, it resets the event, then tries to start the transaction. On the next iteration, thread A would block on the event, and thread B would go through. When it's done, it will set the event back, which will wake up thread A. Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
