Jim,

> No, they aren't alike at all. A resolution agent resolves and preserves

> the resolution of a potential update. The commit sequencer works after
> the fact to see if transactions can be sequenced, not whether
> constraints have been honored.

Are you sure you aren't missing the forrest for the trees?

> The information required for the two mechanisms is radically different.
> A commit sequences needs to know the full read and write sets, so
> if a transaction counted a million records, the commit sequencer needs
> to know not only which million records but which records weren't read
> (e.g. hadn't arrived at that node yet).

Have you actually read and pondered the paper?? A one million record
update would first occur locally, a single, short commit request would be
sent out and when it is received back again a local commit is attempted. If
it fails, we're done. If it commits, a second commit confirmed message
would go out to the other nodes, where we can be certain it will succeed.
Sending write sets as data is an optimisation for simple updates; complex
updates are sent as the (compiled) statement. So it is 1..2 short messages
per write transaction.

> A resolution agent is computationally trivial. To resolve pending

update,

> a resolution agent needs only the table id, record id, and transaction
> id.

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.

> A resolution agent is computationally trivial.

Is that true? Is it still trivial when considering all the network failure
cases? Note how much 2 page Paxos expands when dealing with real world
failure cases.

> A commit sequencer requires a vast amount of data and is incredibly

complex.

Is that true? All that Kemme needed for her proof of concept was the small
Spread library and a 1,000 line patch on Postgres.

I'm ignoring your remarks on serialization, as you have not defined what
you mean by serialization in a distributed context.

Paul