Subject | Re: [Firebird-Architect] Kemme Paper |
---|---|
Author | Jim Starkey |
Post date | 2010-02-06T02:16:54Z |
Roman Rokytskyy wrote:
say that serializable isn't necessary.
My point is that the Kemme scheme is not serializable, which was it's
claim to fame. This does not say that it isn't consistent, but it's an
unnecessarily expensive way to implement consistency. That said, I'm
not prepared to vouch for it's consistency, but I don't have a
counter-example either.
Basically, it typical non-rigorous academic hand-waving. Call it
advanced folk-lore.
latency in the network. OK when everything goes through a Gigabit
switch, but pretty dreadful otherwise.
--
Jim Starkey
NimbusDB, Inc.
978 526-1376
[Non-text portions of this message have been removed]
>> A serializable system will always produce the sequence 0, 1, 2...Sure, but I don't claim to be serializable. In fact, I go further and
>>
>> 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?
>
say that serializable isn't necessary.
My point is that the Kemme scheme is not serializable, which was it's
claim to fame. This does not say that it isn't consistent, but it's an
unnecessarily expensive way to implement consistency. That said, I'm
not prepared to vouch for it's consistency, but I don't have a
counter-example either.
Basically, it typical non-rigorous academic hand-waving. Call it
advanced folk-lore.
> But if you do, then, please correct me if I am wrong, but we will haveIt's a stupid idea. It's performance is directly related to the highest
> {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...
>
>
latency in the network. OK when everything goes through a Gigabit
switch, but pretty dreadful otherwise.
--
Jim Starkey
NimbusDB, Inc.
978 526-1376
[Non-text portions of this message have been removed]