Hi, Ann!

> At 03:00 PM 9/22/2004, Ivan Prenosil wrote:
> >I do not remember exact details, but Nickolay used
> no_record_versions
> >to solve some problems in heavy contention environment (basically,
> >without it nobody was able to do any useful work because of constant
> >lock conflicts/deadlocks)
>
> There's nothing (much)wrong with no_record_versions until
> it's combined with no_wait. Looking back over the archive,
> the combination of options Nickolay used seems to be
> read_committed, no_record_versions, and wait, which is a
> vaguely plausible combination. The application was based on
> a load test adapted from Oracle.

I tried to use this combination to cure endless update conflicts in
high-contention environment.
no_rec_version reduced rate of conflicts, but certainly not eliminated
them.

Oracle equivalent used SELECT ... FOR UPDATE statement to avoid
conflicts.

Problem is that nobody restricts updates to records you read with
no_rec_version after you read them.
As the result you are quite likely to use not current version of the
record and get update conflict exception when you update it later.

Also general transactional behavior of read_committed + no_rec_version +
(wait | nowait) is not usable for generic workloads.
In former case it waits all the time and in latter case fails all the
time under contention.

Now, with pessimistic record locks implemented the only use I can
imagine for no_rec_version modes is to check if somebody updated the
record and to wait until writer finishes.

> Ann

Nickolay