[
https://issues.apache.org/jira/browse/CASSANDRA-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626721#comment-13626721
]
Jonathan Ellis commented on CASSANDRA-5442:
-------------------------------------------
I don't think this is as simple as it looks at first. Suppose we specify
CL.ALL and a node is down. That implies we should throw WriteTimedOutException
-- but which part of the write is it that timed out? I.e., how does the caller
know it was the commit that timed out, and not an earlier stage of Paxos?
In this example a sufficiently smart client could examine the exception and
notice that we were requiring all replicas, and commit is the only part of
Paxos that could do that. But what if we had CL.QUORUM and timed out on
commit? Now this looks like any other time out, and there's nothing that tells
the caller that the proposal was accepted by a majority (and thus will be
visible to the next CAS round or reads at CL.SERIAL).
> Add support for specifying CAS commit CL
> ----------------------------------------
>
> Key: CASSANDRA-5442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5442
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
> Reporter: Jonathan Ellis
> Fix For: 2.0
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
