--- In firebird-support@yahoogroups.com, "tarno_nona" <tarno_nona@...>
wrote:

>
> > A read-committed transaction sees the database as it existed at the
> > time the transaction started, combined with whatever changes it made
> > itself, combined with any committed changes made by anyone else.
> >
> > A read-committed transaction is better when you need to see the latest
> > version of records all the time (quite often used in a read-only
> > read-committed combination).
> >
> Is that mean that read-committed allows lost update to happen? I'm
> confused, I've read Helen's book and I get to conclusion that
> read-committed could prevent lost update to happen but when I did some
> experiment using 2 isql session, both using read-committed, lost
> update still happen.

It may be worth repeating your experiment.

You will either get the second transaction waiting or a lock conflict
depending on the wait parameter (which will eventually succeed or give
the following exception when the first rolls back or commits).

Statement failed, SQLCODE = -913

deadlock
-update conflicts with concurrent update


Adam