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

Ariel Weisberg commented on CASSANDRA-14448:
--------------------------------------------

bq. I want to read what I said to write at LOCAL_QUORUM, and I never do LWT 
again, so I don't use LOCAL_SERIAL in my reads.
:-/

>From one set of documentation:
bq. If lightweight transactions are used to write to a row within a partition, 
only lightweight transactions for both read and write operations should be 
used. 

I didn't find anything on the Apache docs on the subject.

Is that a documented supported behavior? To me it sounds like it's hack based 
on implementation details of LWT. Granted if it's in use we don't necessarily 
want to break it out of the box, but I don't think that means we should prevent 
people who follow the rules from getting better performance.

I think it's a bad idea to set the expectation that LWT should produce correct 
behavior on read when the database doesn't know LWT were involved at write 
time. I think it really narrows the range of approaches that can be taken to 
implement LWT in the future.

> Improve the performance of CAS
> ------------------------------
>
>                 Key: CASSANDRA-14448
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14448
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Coordination
>            Reporter: Dikang Gu
>            Assignee: Dikang Gu
>            Priority: Major
>
> I'm working on some performance improvements of the lightweight transitions 
> (compare and set).
>  
> As you know, current CAS requires 4 round trips to finish, which is not 
> efficient, especially in cross DC case.
> 1) Prepare
> 2) Quorum read current value
> 3) Propose new value
> 4) Commit
>  
> I'm proposing the following improvements to reduce it to 2 round trips, which 
> is:
> 1) Combine prepare and quorum read together, use only one round trip to 
> decide the ballot and also piggyback the current value in response.
> 2) Propose new value, and then send out the commit request asynchronously, so 
> client will not wait for the ack of the commit. In case of commit failures, 
> we should still have chance to retry/repair it through hints or following 
> read/cas events.
>  
> After the improvement, we should be able to finish the CAS operation using 2 
> rounds trips. There can be following improvements as well, and this can be a 
> start point.



--
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