[ 
https://issues.apache.org/jira/browse/CASSANDRA-14635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16581291#comment-16581291
 ] 

Ariel Weisberg commented on CASSANDRA-14635:
--------------------------------------------

There was some discussion about supporting different permutations

* Monotonic reads, no atomicity (blocking read repair)
* Non-monotonic reads, no atomicity (async read repair)
* Non-monotonic reads, atomicity (no read repair)

So maybe allow people to set monotonicity and and atomicity separately and 
error if they set a combination we can't support. For non-monotonic, no 
atomicity we may still want to error out rather than silently give them 
atomicity and have them come to rely on it and then we can't exploit giving up 
atomicity for any reason later.

> Support table level configuration of monotonic reads
> ----------------------------------------------------
>
>                 Key: CASSANDRA-14635
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14635
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Coordination
>            Reporter: Ariel Weisberg
>            Assignee: Blake Eggleston
>            Priority: Major
>
> In CASSANDRA-10726 it was discussed that allowing expert users to forgo 
> monotonic reads might be desirable. It is practical to control monotonicity 
> of reads at a fine grained level because it involves changing the behavior of 
> read repair on a per read basis.
> Per CASSANDRA-14593 we already don't preserve update atomicity down to the 
> column level. You could read the key out of a row and read repair the key, 
> pass the key to another process which attempts to read the value, but finds 
> the value is null because read repair only repairs the data (including 
> columns) that is part of the read. IMO it's a stretch to say that reads are 
> monotonic. It is technically correct, the best kind of correct, but far from 
> as useful as it should be.
> An initial implementation could make read repair asynchronous or forgo read 
> repair entirely. This would improve the throughput and latency of reads.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to