On Jul 31, 2010, at 10:47 PM, Edzard Pasma wrote: > 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.
So why do them within the same transaction? _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
