[
https://issues.apache.org/jira/browse/CASSANDRA-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718268#comment-13718268
]
Sylvain Lebresne commented on CASSANDRA-5797:
---------------------------------------------
bq. Not sure what CQL syntax for this is. Is it protocol level the way CL is?
That's a good question and I'm not really sure what's the right answer.
I think it may make the most sense to make it protocol level because of reads.
For CAS writes, we do have a CQL syntax for it, so we could extends it with say:
{noformat}
UPDATE foo SET v1 = 2, v2 = 3 WHERE k = 1 IF v1 = 1 AND v2 = 1 IN LOCAL DC
{noformat}
But for reads, we don't have any syntax, the consistency level (SERIAL) is the
only thing that makes a read go through paxos, so I'm afraid adding some CQL
syntax in that case would be confusing.
But even making it protocol level is not that easy. For thrift, on the read
side, the only way I can see us supporting this DC-local CAS would be add a
LOCAL_SERIAL consistency level (short of duplicating all read methods for CAS
reads that is). But that doesn't really work for writes since the consistency
level for writes is really the consistency of the paxos learn/commit phase.
One option (the best I can come up with so far) would be to add the
LOCAL_SERIAL consistency level, and then to change CAS write to take 2 CL: the
first one would be for the commit (learn) phase (as we have now, but we would
refuse CL.SERIAL and CL.LOCAL_SERIAL in that case) and a 2nd CL that would
control the "Paxos consistency" (and for that one, only CL.SERIAL or
CL.LOCAL_SERIAL would be valid). It's not perfect however because the one thing
you can't properly express is the ability to do CL.SERIAL for paxos but don't
wait on any node for the learn phase. Unless we make CL.ANY for the "commit
consistency" mean that, but that's a slight stretch.
In any case, we should probably make it sure to shove that in 2.0.0 because I
don't want to change the thrift API nor break the native protocol in 2.0.1.
Any better idea?
> DC-local CAS
> ------------
>
> Key: CASSANDRA-5797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5797
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Affects Versions: 2.0
> Reporter: Jonathan Ellis
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 2.0.1
>
>
> For two-datacenter deployments where the second DC is strictly for disaster
> failover, it would be useful to restrict CAS to a single DC to avoid cross-DC
> round trips.
> (This would require manually truncating {{system.paxos}} when failing over.)
--
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
