On 18 Aug 2010, at 6:33pm, Nikolaus Rath wrote: > 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?
I don't know what you mean by 'cursor'. SQLite has commands. You execute one command at a time. Even a command like a SELECT that gathers lots of data gathers the data all in one go, then finishes. SQLite does not mark its place with one command, then return to that place again with another command. SQLite never locks individual records, it only every locks the entire database file in various ways. > - 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)? SQLite will never know about an impending deadlock, because there's no way to make that information available to SQLite. If your own application knows this information you should be able to take care of it in your own application. Taking care of this situation correctly for arbitrary SQLite requires you to pay attention to the various error conditions like SQLITE_BUSY. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
