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