Op 31-jul-2010, om 14:16 heeft Dan Kennedy wrote:
> > 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. > This is a pity. From the operational point of view, there is no read- consistency required among the original query and the following updates or further queries. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
