On Tue, 02 Feb 2010 11:34:28 -0500, "Ann W. Harrison"
<aharrison@...> wrote:

> Paul,
>>
>>
>> So we have a one million record update which fails on the last record.
>> One
>> million messages get send to request update of each record, and a
>> provisional ok gets returned for 999,999. Then the last one fails, so

we

>> get 999,999 "transaction rolled back" messages to the same records.

That

>> is
>> 2 million messages. With a UDP latency of 0.5 ms, that is 1,000 seconds
>> for
>> this statement, or about 16 minutes.
>>
>
> Or the failure is on the first update, but is not detected on the
> local system. The transaction continues for another 999,999 rows,
> fat, dumb, and happy...

Assuming that you are not being cynical, this leads me to think the
following. Of course you are not waiting for the response on each request,
as that would lead to impractical response times. Local processing
continues, and if any responses are still outstanding when it is about to
commit it will only then wait for those replies to come in and make its
commit/rollback decision.

Now, with local processing much faster than network communications for
most queries, I would think that the vast majority of transactions will
experience such a brief interlude just before committing/rolling back.
There is nothing wrong with that, but I do note that this is also the point
where a commit sequencer system will have its brief network interlude.

At my current level of understanding I would say that Jim's design
achieves a higher level of parallelism than the Kemme design
(consistent+fifo order on writes vs. total order on writes) at the cost of
increased communication (1..2 reliable messages per record updated vs. 1..2
ordered messages per committed write transaction).

Which is better? Only benchmarking will tell I think.

Paul