thanks for your answer DuyHai.
I understand Paxos. but I think your description seems missing one important point: in the example you gave, "a series of ongoing operation (INSERT, UPDATE , DELETE ...) " you seem to be suggesting that the "other operations on the same partition key have to wait" because Paxos grouped the first series together, which have to be committed in the same order , before all other operations, essentially ___serializing___ the operations (with guaranteed same order).
but Paxos ONLY guarantees order of the operations as they are proposed. Paxos itself can not control when a operation is proposed. for example in the above sequence . INSERT, UPDATE , DELETE,.... the second guy is fully allowed to propose his operation (say another UPDATE) before DELETE is proposed, and hence get the latest ballot number (smaller than that for DELETE), so the final committed sequence is INSERT UPDATE op_from_another_guy, DELETE ......
I guess Cassandra must be doing something to prevent "the second guy injecting his operation before DELETE" in the above scenario, that seems to be some transaction manager which is not yet clearly described in the slides u gave.
if that is correct,
my point is, if we let the above transaction manager work with the standard replication protocol, don't we also get transaction behavior?