Hi, If my understanding is correct, as long as you know that at least one node acknowledge a write, it will be replicated at some point in the cluster. A retry failure depends on what you consider a failure :)
If you absolutely need LOCAL_QUORUM to succeed, and for any reason Cassandra can't at the time you try to use it, then I believe you have to kind of rollback. But again, if the first write can't be done at LOCAL_QUORUM, neither will your rollback => This must be what Edward called " a square peg round hole discussion" I personnaly believe that, with a well planned repair strategy, plus read_repair and hints mecanism, downgradingConsistencyRetryPolicy is quite acceptable in term of consistency Again, there are no magic rules when it comes to handle exception, because it deeply depends on what you want to achieve. Nicolas On 16 February 2017 at 16:33, rouble <r.ou...@gmail.com> wrote: > Thanks for the links. I get that all queries need to be idempotent, and we > should use retries for data consistency. > > But, what happens when the retries fail? Then, the data *may* be there. To > maintain consistency we need to rollback any created data, correct? > > tia, > rouble > > On Wed, Feb 15, 2017 at 4:53 AM, Nicolas Guyomar < > nicolas.guyo...@gmail.com> wrote: > >> Hi Rouble, >> >> I usually have to read javadoc in java driver to get my ideas straight >> regarding exception handling. >> >> You can find informations reading : http://docs.datastax.com/en/ >> drivers/java/3.1/com/datastax/driver/core/policies/RetryPolicy.html and >> for instance http://docs.datastax.com/en/drivers/java/3.1/com/da >> tastax/driver/core/policies/DowngradingConsistencyRetryPolicy.html with >> the onWriteTimeout method which differentiate several case of error. >> >> As Edward stated, you can know how many replica acknowleged the write in >> Cassandra response. >> >> Keep in mind that retrying usually mean your write query is idempotent or >> you don't care having duplicate entries >> >> >> On 14 February 2017 at 21:49, Edward Capriolo <edlinuxg...@gmail.com> >> wrote: >> >>> >>> >>> On Tue, Feb 14, 2017 at 2:30 PM, rouble <r.ou...@gmail.com> wrote: >>> >>>> Cassandra Gurus, >>>> >>>> I have a question open on stackoverlow on how to determine if data is >>>> actually created when a Write exception is thrown: >>>> http://stackoverflow.com/questions/42231140/determin >>>> ing-if-data-will-be-created-on-cassandra-write-exceptions >>>> >>>> From my discussion on the question, it seems that on *any* Cassandra >>>> write, *any* exception, means the data may or may not be written. With the >>>> exception of InvalidQueryException. >>>> >>>> I find this unsettling. Maybe I need time to adjust from my RDBMS >>>> background, but how is Cassandra supposed to be used for systems that need >>>> user feedback? or is it? >>>> >>>> Let me use the simple example of account creation. User tries to create >>>> an account, and we need to indicate one way or the other whether the >>>> account was created. Lets say a WriteTimeoutException is thrown while >>>> trying to add the user. User may or may not be written, what do we tell the >>>> user? Should we just rollback the change and tell the user that it failed. >>>> This seems like the only thing we can do deterministically (and I notice >>>> someone doing just that here: http://stackoverflow.com/a/348 >>>> 60495/215120). >>>> >>>> How are people handling WriteTimeoutExceptions or >>>> UnavailableExceptions? Rolling back in every case does not seem practical. >>>> >>>> tia, >>>> Rouble >>>> >>> >>> There is a difference between WriteTimeoutException and >>> UnavailableException. >>> >>> UnavailableException indicates the write was never even attempted. >>> >>> WriteTimeoutException means the write was attempted. I believe you can >>> interrogate the exception to determine if the operation was successful on >>> any of the natural endpoints. >>> >>> The way to "cope" is idempotent writes and retries. If that model does >>> not fit it is a square peg round hole discussion. >>> >> >> >
