cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rouble <>
Subject Re: Determining if data will be created on Cassandra Write Exceptions
Date Thu, 16 Feb 2017 15:33:41 GMT
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?


On Wed, Feb 15, 2017 at 4:53 AM, Nicolas Guyomar <>

> Hi Rouble,
> I usually have to read javadoc in java driver to get my ideas straight
> regarding exception handling.
> You can find informations reading :
> drivers/java/3.1/com/datastax/driver/core/policies/RetryPolicy.html  and
> for instance
> datastax/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 <>
> wrote:
>> On Tue, Feb 14, 2017 at 2:30 PM, rouble <> 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:
>>> 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:
>>> ).
>>> 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.

View raw message