Sean wrote:

>
> 1. I have a table with 3 columns, {ID, A, B}.
>
> There are two transactions, TransA and TransB. TransA updates column A
> of a row, and TransB updates column B of the *same* row. Both
> transactions use READ COMMITTED isolation with RECORD_VERSION.
>
> Say, TransA comes in first and then TransB. TransA modifies the column
> A and commits. TransB updates column B. Since TransB's TID is newer
> than TransA's, TransB can commit the modification successfully, I think.

TransB updates the version of the record that A committed, as long as
it doesn't have to wait for A. If it waits, it will get an error when
A commits.

>
> My question is, what is the value of column A? Is it the value from
> TransA? I hope the value is not reset back to original value by TransB.

The value from TransA.

>
> 2. Update conflict means when a transaction tries committing and fails
> because the latest committed version has changed.

Not committing - the error happens on the update. Firebird's MVCC isn't
really an optimistic concurrency transaction system - it's a bit more
cheery than most record or page locking schemes, but still returns
errors on the operation, not on commit.

>
> The question is, when does a transaction remember the latest committed
> version? At the begin of the transaction?

A concurrency (aka snapshot mode) transaction gets the state of
transactions at its start. A read-committed transaction updates
the state of transactions as it reads records.

Regards,


Ann