This is not a good example i think. If a transaction is intent to update after the select, it should start a write lock before the select. And as described in previous 'dead lock' example, the update in this example could fail due to 'dead lock' I believe the 'read lock' is designed for a 'read only' transaction, and the 'write lock' is for a transaction that 'may write something'.
2009/9/19 Igor Tandetnik <itandet...@mvps.org> > 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. > > Of course, if that's what the application wants, it can simply perform > the read and the write operations in two separate transactions. > > Igor Tandetnik > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Best Regards, ZHAO, Wenbo ======================= _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
