Op 31-jul-2010, om 18:30 heeft Dan Kennedy wrote: > > 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?
That is not on purpose. It may occur if one uses more than one cursor with a single connection even in auto-commit mode. I thought this deadlock is fairly common with SQLite. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
