Page History

...

• General purpose transactions (may operate over any keys in the database at once)
• Strict-serializable isolation
• Optimal latency: one wide area round-trip for all transactions under normal conditions
• Optimal failure tolerance: latency and performance should be unaffected by any minority of replica failures
• Scalability: there should be no bottleneck introduced
• Should have no intrinsic limit to transaction complexity
• Must work on commodity hardware
• Must support live migration from Paxos

User Impact

Grammatically correct CQL operations that would be rejected for operating over multiple CQL partitions will now be supported, e.g.

BEGIN BATCH
UPDATE tbl1 SET value1 = newValue1 WHERE partitionKey = k1
UPDATE tbl2 SET value2 = newValue2 WHERE partitionKey = k2 AND conditionValue = someCondition
APPLY BATCH

Long Term

This work is expected to replace Paxos for the project. In order to support live migration both protocols will be maintained for at least an interim period, after which it is expected that Paxos will be deprecated. The precise timing of this will be up to the community.

Non-Goals

• UX improvements to exploit this facility are considered out of scope, and will be addressed in separate CEP

...