On 1/2/08, Lior Okman <[EMAIL PROTECTED]> wrote: > Trevor Talbot wrote:
> > Requiring the second transaction to complete first is expected in > > terms of SQLIte's concurrency system. > So in terms of using SQLite, I need to close the entire transaction and > restart it when I get a "database locked" return code in a writer > thread? It's not enough to just retry the commit in a little while? It's safe to retry a commit. It may not be safe to retry a writing statement, depending on the presence of other writers. These two messages should help explain what you need to consider to avoid deadlocks: http://www.mail-archive.com/sqlite-users@sqlite.org/msg27284.html http://www.mail-archive.com/sqlite-users@sqlite.org/msg28638.html > Wouldn't it be more intuitive to allow the single handle holding the > RESERVED lock to finish? Right now, the SQLite behaviour allows only the > serialized isolation level. Making this change would make the isolation > level be more like "read committed". You could get that behavior now by simply not using an explicit transaction in the reader. Actual "read committed" isolation support comes in when there are concurrent writers, so one transaction can see its own changes as well as the changes of others that have committed in parallel. Keep in mind, SQLite has no central transaction arbiter managing the file; its concurrency is implemented in terms of OS-level file locks. In order to implement parallel writers at any isolation level, a writer would need to somehow distinguish its changes from those of other writers in progress. That makes the act of committing itself, as well as crash recovery, much more complex. It also has to deal with potential conflicts on pending changes, and with "read committed" as an option, it's complicated even more by transactions using a mix of isolation levels. A very difficult kind of change. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
