[
https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165151#comment-14165151
]
Blake Eggleston commented on CASSANDRA-6246:
--------------------------------------------
Since epaxos executes mutations at different times on each machine, each
instance needs a serialized copy of the statement. The CQL3CasRequest.RowUpdate
class keeps a reference to the actual ModificationStatement, and serializing
that looks like it will involve implementing at least 50 (de)serializers. Since
I’m not super familiar with the inner workings of the UpdateStatement and
DeleteStatement, I thought I’d ask here to see if there’s a better solution I’m
not seeing.
> 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)
