Christopher Batey commented on CASSANDRA-12625:

We can, though my preferred way of adding that information would probably be to 
add a new boolean to WriteTimeoutException when WriteType is CAS to indicate if 
we can guarantee it won't be applied or not (could call it canSafelyReply for 

Agreed. This can still be made applicable even if we entirely change our paxos 
algorithm e.g. epaxos

I'll put together a patch.

> Distinguish between CAS prepare and propose failures
> ----------------------------------------------------
>                 Key: CASSANDRA-12625
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12625
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Christopher Batey
>            Assignee: Christopher Batey
>            Priority: Minor
>              Labels: cas
>             Fix For: 3.x
> I spoke to a lot of users at the summit and had the feedback that the hardest 
> part of building applications using LWTs is dealing with WriteTimeouts of 
> type CAS.
> Following up from https://issues.apache.org/jira/browse/CASSANDRA-8672 I 
> think we should add a separate WriteType for timing out during the prepare 
> phase assuming we can advise users to retry the operation or be confident it 
> has failed as it won't be completed by a later SERIAL read or LWT.
> We can't remove the ambiguity at the propose phase but this will remove one 
> of the unknown cases.
> cc [~slebresne] [~bdeggleston] [~spo...@gmail.com]
> Happy to do a patch for this but assuming it will need a native protocol 
> change when can we do it?

This message was sent by Atlassian JIRA

Reply via email to