>> The point that I am making when talking about "ordering" is *not* the
>> ordering on a single node, but the relative ordering between nodes. If
>> snapshot isolated transaction A commits before snapshot isolated
>> transaction B and if both A and B updated the same record, then and

only

>> then must A commit before B on all nodes.
>
> In the Firebird/Netfrastructure/NimbusDB world, that case requires
> that B fail.

Only if A commits after B started, otherwise it succeeds (assuming no
other conflicts).

> The other model - mixed snapshots and locks - allows
> B to wait for A's commit and proceed with its updates. That's a
> great advantage for TPC/C, but, as I said, it has some odd side-effects.
>
> If write-ordering is performed at commit, and running transactions
> see a stable snapshot of data, how does the system detect and avoid
> lost updates? For example, Transaction A does a bunch of stuff
> including updating a specific record by adding 5 to one field.
> Transaction B does the same, including updating the same record.
> Neither sees the other's change. Even if B waits for A to commit
> everywhere, it will still have read an old value and stored a value
> that doesn't include A's change. Yes, all copies of the database
> will have the same result, but A's change is lost on all of them.

How about the "new jersey" solution: B fails on commit because of a
concurrent update and restarts itself from the beginning in a new
transaction, either automatically or with the application's help? In
today's world, where transactions tend to be short, the cost is modest as
compared to the gain of scaling out.

Paul