I was talking about this example by 2009/9/19 Igor Tandetnik <itandet...@mvps.org> "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."
What I want to say is in this example, there should be only one step, because the transaction knows it will do 'write'. Then the txn should start a write lock before the select. And this is not a good example to explain dead lock, I think. 2009/9/19 Pavel Ivanov <paiva...@gmail.com> > Wenbo, are you talking about what do you want to see in DBMS or are > you trying to explain how SQLite works? > If the latter then you're wrong. In SQLite 'read lock' is designed for > transaction that _made_ any reads, 'write lock' - for transaction that > _made_ any writes. > > Pavel > > On Sat, Sep 19, 2009 at 12:18 AM, Wenbo Zhao <zha...@gmail.com> wrote: > > 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 > > > _______________________________________________ > 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
