Igor Tandetnik wrote:
> Angus March <[email protected]> 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
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
