Helen Borrie wrote:

>
> 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.
>...
> 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.

Your explanations were incredibly detailed and clearer than I have read
anywhere else. I thank you dearly for doing this for me.

I have now come to terms with the fact that ReadCommitted transactions
with RecVersion = False will only provide a warning if a simultaneous
transaction has *not* committed. If it *has* committed, then
the current update succeeds and the previously unknown value committed
by that simultaneous transaction is the one that is lost by being
overwritten by the latest update.

Now I understand that

"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."

means

"simultaneous transactions, without any loss of current transaction's
updates, but all previously committed values are lost."

Thank you.
--
Raymond Kennington
Programming Solutions
TeamW2W (InfoPower)