> A serializable system will always produce the sequence 0, 1, 2...
>
> In the Kemme scheme, each node executes a transaction locally and
> forwards the write set to all remote nodes. Two replicas execute
> concurrent transaction. Each sees zero record, and each inserts a
> record with value zero. The write sets are independent. Remote nodes
> execute the transaction, commit both, and the table now has the values {
> 0, 0 }, which violates serializability.

Isn't that the case with your approach as well unless you define a
unique constraint?

But if you do, then, please correct me if I am wrong, but we will have
{0, 1, 2, 3, ...} at the end in case with total ordering, though 50% of
transactions will fail. Or maybe {0, 2, 4, 6, ...}, but anyway the
constraint will be satisfied and database will be formally consistent.

> I have other issues as well, mostly with the concept of totally ordered
> messages. This may work for a LAN where latencies are short, but it is
> total bullshit on a WAN or Internet. Put one slow connection into mix
> and communication approximately stops.

Yes, that is the issue, though I wonder what are the latencies in a data
center of Google or Amazon...

But in fact GCS is very sensitive tool - put one parameter of many
wrong, and you get very slow performance.

> The paper states the total ordering can deliver hundreds of message per
> second. Since each commit require two messages (one to send the commit
> and another, ordered, to reapply the commit), this strikes me as pretty
> feeble.

At the moment I try to get Spread to run on my Win7 box to check how
many total order messages I can get in my home LAN. It does not work at
the moment...

Roman