Bill King <[EMAIL PROTECTED]> wrote: > Christian Smith wrote: > > > > If one transaction already has a read lock, and another transaction > > has a reserved lock (trying to get a write lock), neither thread can > > get a write lock. One of the transactions must abort. > > > > Such a sequence might be (in order): > > Transaction 1: BEGIN; SELECT ... > > Transaction 2: BEGIN; DELETE ... (SQLITE_BUSY) > > T1 : UPDATE ... (SQLITE_BUSY) > > > > Both transactions are now deadlocked. > > > > It would be nice if SQLite told us this. However, SQLite detects the > > reserved lock and returns SQLITE_BUSY, telling niether transaction > > much other than to try again. If a reserved lock is detected when > > trying to promote an existing read lock, this is a deadlock situation > > and should perhaps return an error code of SQLITE_DEADLOCK instead? > > According to DRH this scenario shouldn't happen. Begin should set a > flag, and the second begin will bug out because the flag is set. This is > what looks like happening in my scenario, and is definately wrong > behaviour.
The flag that is set is private to each sqlite3 database connection. So setting the flag in one connection should not have any effect on any other connection. -- D. Richard Hipp <[EMAIL PROTECTED]>
