On Jul 31, 2010, at 12:02 AM, Edzard Pasma wrote: > Hello, > > The following scenario raises a BUSY error immediately > > process A. keeps a write lock > process B keeps a read-lock and tries to promote this to a write-lock > > This is the traditional SQLite deadlock situation, detected by the > engine as soon as possible. > > In my test this still occurs unchanged after switching to WAL. Should > process B not be allowed to carry on now? Using WAL, A. can still > commit while B. keeps a read-lock.
A can commit while B has the read-lock. But there is no point in B using the busy-handler to wait until A has committed, because after A has committed B will be reading from an out-of-date snapshot. And you cannot update the database if you are reading from an out-of-date snapshot. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
