[
https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152316#comment-14152316
]
sankalp kohli commented on CASSANDRA-6246:
------------------------------------------
Currently we do a read on quorum/local_quorum and based on that value decide if
the condition matches at the co-ordinator.
With you approach, the decisions will now be local and could be different on
different replicas. If some replica some how lags behind due to various
reasons, the condition on it will never be satisfied going forward.
Coming back to my suggestion from previous comment, if all replicas respond
back with all committed before this instance and things are the same, we can
use the read value. Correct?
> EPaxos
> ------
>
> Key: CASSANDRA-6246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Blake Eggleston
> Priority: Minor
>
> One reason we haven't optimized our Paxos implementation with Multi-paxos is
> that Multi-paxos requires leader election and hence, a period of
> unavailability when the leader dies.
> EPaxos is a Paxos variant that requires (1) less messages than multi-paxos,
> (2) is particularly useful across multiple datacenters, and (3) allows any
> node to act as coordinator:
> http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
> However, there is substantial additional complexity involved if we choose to
> implement it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
