Igor Tandetnik wrote: > Angus March <an...@uducat.com> wrote: > >> Pavel Ivanov wrote: >> >>>> Hell if I know why they use fcntl() for locks, and don't even give >>>> you the option to block. >>>> >>>> >>> I think because they need to detect dead locks. BTW, I believe in >>> case of dead lock even busy_handler will not be called, just >>> SQLITE_BUSY is returned... >>> >>> >> I guess that makes sense, in cases where multiple tables are >> involved. >> > > It doesn't matter whether a single or multiple tables are involved - > SQLite locks at the database level. The deadlock occurs when 1) > transaction A starts to read, taking a SHARED lock; 2) transaction B > prepares to write, taking a RESERVED lock; 3) transaction A now wants to > write, too. At this point, transaction B is waiting for all readers (one > of which is transaction A) to clear, while transaction A waits for the > previous writer (which is transaction B) to complete. >
Yes, I see. So what is key to the problem is that someone tries to change their read lock to a write lock. I guess I just thought that the kernel that manages fcntl() would have a way of dealing with this. Can this situation not be averted if at step 3, transaction A releases its read lock before requesting a write lock? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users