> Maybe you are suggesting a more radical approach where a transaction
> executes completely locally recording all reads, probes (records that
> would have been read if they existed), and writes, then at commit time
> sends the log to a commit sequencer who maintains global state, and
> either rejects the commit for broad casts the log to all nodes to apply
> locally. I suppose it could be made to work (the probes -- aka phantom
> control -- are very, very tricky). However, the commit analysis must be
> serialized. So either you're going to have to find a way to distribute
> the function or face a central bottleneck that limits the performance.
> But perhaps you can find a way around that problem.

Did you check the Paxos algorithm for such case?

From what I remember from a paper by L.Lamport, it allowed reaching an
agreement even when particular node in a cluster crashes and later
rejoins the cluster or one node replies significantly slower than
others. It seems to be quite popular in the "NoSQL-movement" (or rather
"key-value"-movement), but AFAIR there was some research also in
relational databases...

I have a feeling, that if we consider a complete transaction as an
update in a key-value store, the cluster members can then vote on the
complete transaction outcome.

Roman