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
On Apr 22, 2008, at 6:52 PM, Igor Tandetnik itandetnik-at-mvps.org |
sqlite| wrote:
> 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
On Apr 22, 2008, at 6:52 PM, Scott Hess shess-at-google.com |sqlite|
wrote:
> 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
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
>
>
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
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
6 matches
Mail list logo
