Subject | Kemme Paper |
---|---|
Author | Jim Starkey |
Post date | 2010-02-05T23:34:17Z |
I'm looking at it, but the flaw in the argument is simple: It isn't
sufficient to look at write sets to determine transaction order for the
purpose of preserving serializability.
The counter-example is what I call the Noyce transaction:
* One table with one numeric column
* One transaction type: Count the records and store a new row with
that value.
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.
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.
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.
But, maybe I've missed something. If so, I'm sure somebody will set me
right.
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376
[Non-text portions of this message have been removed]
sufficient to look at write sets to determine transaction order for the
purpose of preserving serializability.
The counter-example is what I call the Noyce transaction:
* One table with one numeric column
* One transaction type: Count the records and store a new row with
that value.
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.
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.
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.
But, maybe I've missed something. If so, I'm sure somebody will set me
right.
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376
[Non-text portions of this message have been removed]