using BEGIN IMMEDIATE would prevent this situation from happening, right? Process 2 would get the lock error when it tries to begin the transaction and thus never obtain a reserved lock which prevented process 1 from promoting to an exclusive lock for commit.
Sam ----------------------------------------------------------------- We're Hiring! Seeking passionate Flex, C#, or C++ (RTSP, H264) developer. Position is in the Washington D.C. metro area. Contact [EMAIL PROTECTED] On Tue, Jun 10, 2008 at 7:19 PM, Igor Tandetnik <[EMAIL PROTECTED]> wrote: > Dave Dyer <[EMAIL PROTECTED]> wrote: > > I don't understand why the following transaction > > behavior is correct or necessary. The question > > involves two simultaneous transactions on the same > > database > > > > Process 1 Process 2 > > > > BEGIN > > > > BEGIN > > > > insert... > > > > insert... fails "locked" > > > > end also fails "locked" > > > > It seems that the end of a transaction can > > fail even if all the intermediate actions > > succeeded. > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
