Igor Tandetnik wrote:
> Angus March <an...@uducat.com> wrote:
>
>> 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?
>>
>
> Then it wouldn't be much of a transaction, now would it? Imagine the
> classic example, where a transaction first verifies that the balance in
> a bank account is sufficient, then performs a withdrawal. If it
> relinquishes all locks between these two steps, then somebody else may
> record a withdrawal from that account, so that the write operation would
> then make the balance negative, thus violating an invariant.
>
Oh, when you said "transaction" you meant a transaction. I find that
term (among a few others) gets used rather liberally in sqlite
subculture. Yes, fortunately, fcntl() can fail with a EDEADLK error
wherein "It was detected that the specified F_SETLKW command would cause
a deadlock." Maybe that would be a better time for functions to fail
with SQLITE_LOCKED, making the blocking less than perfect, but but at
least there'd be *some* of it.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
