There is no recovery from this situation- If you try to rollback, you get the following error -"cannot rollback savepoint, SQL statments in progress" or if you dont use SAVEPOINT - "cannot rollback, no transaction is active " If you start the transaction with BEGIN IMMEDIATE in App1, the writer in App2 gets the following error " database is locked"
Sreekumar On Fri, Feb 10, 2012 at 8:13 PM, Igor Tandetnik <itandet...@mvps.org> wrote: > Marc L. Allen <mlal...@outsitenetworks.com> wrote: > > I see. So, the implied commit doesn't occur until you finalize? > > Or reset. > > > As a result, the subsequent update in step 5 was added to his > > non-finalized select? > > The update was attempted within the same transaction. > > > Still.. what is the correct way to handle the explicit scenario? I > mean, having one process do a BEGIN SELECT UPDATE and another > > do BEGIN UPDATE is perfectly reasonable, isn't it? How do you protect > from a problem? Detect the error, rollback, and try > > again? > > That's one way. The other is for the first connection to start its > transaction with BEGIN IMMEDIATE, thus marking itself as a writer from the > start. > -- > Igor Tandetnik > > _______________________________________________ > 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
