In the real code, there is no sleep/wait or pause. It so happens that the
write of the app2 is scheduled in between.

What you are suggesting is that at any point of time only one process can
have a transaction open in a database?


Sreekumar
On Feb 10, 2012 7:12 PM, "Simon Slavin" <slav...@bigfraud.org> wrote:

>
> On 10 Feb 2012, at 1:32pm, Sreekumar TP wrote:
>
> > well, the 'wait' is a simulation of what happens in the real code.
> >
> > The error is fatal to the application as it never ever recovers from it
> > even though the writer has finalized and terminated.
>
> In a multi-process environment I recommend that you do not pause for such
> a long time between the first _step() and the _reset() or _finalize().  You
> can _bind() a statement then wait a long time to execute it, but once you
> have done your first _step() you want to get through the data and release
> the database for other processes.
>
> If you still have the database locked and another process tries to modify
> it, one process or the other will have to deal with a BUSY, or a LOCKED, or
> something like that.  In your own setup, it turns out to be process 1.  But
> a slightly different setup would make process 2 see a BUSY instead.
>
> Simon.
> _______________________________________________
> 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

Reply via email to