At 12:51 PM 14/08/2003 +0930, you wrote:

>Jason Wharton wrote:
> >
> > > Then should the GSG be corrected?
> > >
> > > In the GSG: "Transaction Terminology"
> > >
> > > "READ COMMITTED enables the transaction to see all committed data
> > > in the database, and to update rows updated and committed by other
> > > simultaneous transactions, without any loss of updates."
> >
> > There is nothing to correct. Made more explicitly clear, perhaps.
>
>Updates committed by other simultaneous transactions are lost.
>
>This is incompatible with
> "... without any loss of updates".

Updates committed by other simultaneous transactions are not lost. They DO
succeed. However, in ReadCommitted isolation with RecVersion True, they
will ordinarily risk being overwritten by a version based on an earlier
committed version. This situation is not a problem in most situations and
it keeps the level of conflict low. At the same time, if you have a
particular situation, where users have a high likelihood of stepping on one
another's work, you have to configure your transactions more pre-emptively.

This is because, in Read Committed isolation, with RecVersion set to True,
each transaction considers only the latest committed version of the
record. It gets to overwrite this regardless of any uncommitted versions,
even if these uncommitted versions are more recent than the one it used as
its basis.

Still in ReadCommitted, you can change this behaviour by setting RecVersion
to False. Now, if your transaction tries to post a new version based on
the latest committed version, it will be locked out if another transaction
has already posted (but not committed) a newer version.
--- If LockWait is False, it "deadlocks" immediately.
--- If LockWait is True, it will wait until the other posted new version is
either committed or rolled back. If the other version is committed, your
commit request fails. If the other version is rolled back, your commit
request succeeds. If the other version isn't very likely to be rolled back,
it is pretty pointless to use LockWait.

At your request, I spent a considerable amount of time at the weekend
explaining this to you in private email. I explained the alternative
effects you can get by using tiConcurrency, with or without LockWait; and
by using PessimisticLocking. Let me know if this email never arrived, and
I will resend it.

Helen