Paul,
Taking your points in reverse order ...

> What is not getting through my thick skull, so that you and Jim keep
> demonstrating that snapshot isolation is not serializable, which to
> me is a truism?

My message was not directed at you specifically, but to expand on
the difference between consistent read and serializability. I'm
actually working on a short essay about a different sort of concurrency
control that uses record locking to order writes and snapshots for
repeatable read. It has some advantages and some, well, strangeness.

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

Current implementations of SQL - that I know of - add five to a
value by reading the value, adding five to it, and writing back
the result. Having an implementation or a new language that
understand the concept of adding five as separate from the old
result might avoid this specific simple problem, but there are
other cases, more like my second example that produce lost updates
based on more complex interactions if there is write ordering
without read ordering.


At least that's the way it looks to me - and maybe I just missed
the point.


Cheers,

Ann