On Fri, Feb 10, 2012 at 11:45 AM, Sreekumar TP <sreekumar...@gmail.com>wrote:
> There is no recovery from this situation- > The recovery from your situation is to reset or finalize the initial query that is holding the transaction option. > > 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 > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
