Nikolaus Rath <[email protected]> writes: > Dan Kennedy <[email protected]> writes: >> On Aug 17, 2010, at 1:48 AM, Nikolaus Rath wrote: >> >>> Hello, >>> >>> The script below fails with >>> >>> Deadlock detected when executing 'DELETE FROM foo WHERE id=2' >>> >>> What I think should be happening instead is this: >>> >>> - When executing statement 1, the main thread obtains a SHARED lock. >> >>> - When executing statement 2, the main thread briefly obtains an >>> EXCLUSIVE lock. After statement 2 is executed, the EXCLUSIVE lock is >>> released and the main thread continues to hold the SHARED lock >>> (since >>> statement 1 is still active) >> >> Quite correct. > > Hmm. That's quite the opposite of what Igor said in his mail. Who is > right now?
Still no one able to clarify the issues raised in this thread? Let me try to summarize what I still don't understand: - Will SQLite acquire and release an EXCLUSIVE lock while keeping a SHARED lock if one executes a UPDATE query with one cursor while a different cursor is in the middle of a SELECT query, -or- will the EXCLUSIVE lock be held until the SELECT query finishes? - Is there a way to prevent SQLite from keeping the SHARED lock while waiting for an EXCLUSIVE lock if doing so would result in a deadlock (because another connection holding a SHARED lock needs to get an EXCLUSIVE lock before it can release the SHARED lock)? Thanks, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
