[
https://issues.apache.org/jira/browse/CASSANDRA-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179980#comment-15179980
]
Marcus Olsson commented on CASSANDRA-11258:
-------------------------------------------
bq. WDYT of this approach?
I like it, it would reduce the amount of work for the write operations while
keeping a simple structure of the lock keyspace. However, *if* we want to
visualize all data center locks to the user, it would be more complex to do so.
bq. If you like this approach, we could do the initial version assuming a
single DC with SimpleStrategy replication + SERIAL consistency, while power
users could still have multi-DC support by manually changing replication
settings of the lock keyspace. We could later add transparent/efficient
multi-DC support via CASSANDRA-11300 and LocalDataCenterReplicationStrategy.
+1
Should we start with {{SimpleStrategy}} and a replication of 3 then? If we only
have one node there would be no need for repairs and if we have two it would be
possible to do CAS requests. If we include the
{{LocalDataCenterReplicationStrategy}} class directly in the first version but
use SimpleStrategy until CASSANDRA-11300 is in place it should be possible to
switch to LDCRS automatically later on, assuming that repairs would be paused
during that upgrade. If we don't include LDCRS directly I think the switch
would either have to be manual or done by first verifying the version of the
other nodes, so that the "older" nodes wouldn't complain about an unknown
replication class.
> Repair scheduling - Resource locking API
> ----------------------------------------
>
> Key: CASSANDRA-11258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11258
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Marcus Olsson
> Assignee: Marcus Olsson
> Priority: Minor
>
> Create a resource locking API & implementation that is able to lock a
> resource in a specified data center. It should handle priorities to avoid
> node starvation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
