Subject Snapshot Isolation in A Critique of ANSI SQL Isolation Levels
Author Ann W. Harrison
Hello all,

Being a serious masochist, I've undertaken a review of the
academic literature on multi-version concurrency control, also
called snapshot isolation, multi-generational concurrency and
a few other things. The state of the literature is at best
uneven. But here is a paragraph from the 1995 paper by
Berenson, Bernstein, Gray, Melton, O'Neil, & O'Neil. Does anyone
know of a system actually implemented that works like this?

"Snapshot Isolation admits a simple implementation modeled on
the work of Reed [REE]. There are several implementations of
such multi-version databases, Borland's InterBase 4 and the
engine underlying Microsoft's Exchange System both provide
Snapshot Isolation with the First-committer-wins feature.
First-committer wins requires the system to remember all
updates (write locks) belonging to any transaction that
commits after the Start-Timestamp of each active transaction.
It aborts the transaction if its updates conflict with
remembered updates by others."

My specific question is whether any system actually collects
potential conflicts and analyzes them at commit time rather
than recognizing the conflict on update and resolving it by
requiring the second concurrent transaction trying to update
or delete a row to wait for the outcome of the first transaction?

A second, more general question is whether anyone knows
of a database in commercial use that tries to order transactions
based on their relative start time (as Reed does) rather than
having each new transaction note the state of other transactions
at that instant?