[ 
https://issues.apache.org/jira/browse/CASSANDRA-13419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedict Elliott Smith updated CASSANDRA-13419:
-----------------------------------------------
    Component/s: Feature/Lightweight Transactions

> Relax limit on number of pending endpoints during CAS
> -----------------------------------------------------
>
>                 Key: CASSANDRA-13419
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13419
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Feature/Lightweight Transactions, Legacy/Coordination, 
> Legacy/CQL
>            Reporter: Ariel Weisberg
>            Assignee: Ariel Weisberg
>            Priority: Normal
>              Labels: LWT
>
> CASSANDRA-8346 avoids stale reads during CAS when checking the condition or 
> doing serial reads by disallowing more than one pending endpoint.
> It seems like it should be possible to allow more than one pending endpoint 
> by being smarter about who we read from during the QUORUM read or about the 
> state of pending nodes that are there for host replacement.
> Sylvain suggested 
> bq. Well, I guess things are working as they do for decently good reason 
> here. That said, thinking about it, it could be that the solution from 
> CASSANDRA-8346 is a bit of a big hammer: I believe it's enough to ensure that 
> we read from at least one replica that responded to PREPARE 'in the same 
> Paxos round' But we have timeouts on the paxos round, so it could be it is 
> possible to reduce drastically the time we consider a node pending for CAS so 
> that it's not a real problem in practice. Something like having pending node 
> move to a "almost there" state before becoming true replica, and staying in 
> that state for basically the max time of a paxos round, and then Paxos might 
> be able to replace "pending" nodes by those "almost there" for PREPARE.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to