cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4806) Consistency of Append/Prepend on Lists need to be improved or clarified
Date Tue, 16 Oct 2012 13:53:04 GMT


Jonathan Ellis commented on CASSANDRA-4806:

> Consistency of Append/Prepend on Lists need to be improved or clarified
> -----------------------------------------------------------------------
>                 Key: CASSANDRA-4806
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>    Affects Versions: 1.2.0 beta 1
>            Reporter: Michaël Figuière
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.2.0 beta 2
> Updates are idempotent in Cassandra, this rule makes it simple for developers or client
libraries to deal with retries on error. So far the only exception was counters, and we worked
around it saying they were meant to be used for analytics use cases.
> Now with List datatype to be added in Cassandra 1.2 we have a similar issue as Append
and Prepend operations that can be applied on them are not idempotent. The state of the list
will be unknown whenever a timeout is received from the coordinator node saying that no acknowledge
could be received on time from replicas or when the connection with the coordinator node is
broken while a client wait for an update request to be acknowledged.
> Of course the client can issue a read request on this List in the rare cases when such
an unknown state appear, but this is not really elegant and such a check doesn't come with
any visibility or atomicity guarantees.
> I can see 3 options:
> * Remove Append and Prepend operations. But this is a pity as they're really useful.
> * Make the behavior of these commands quasi-idempotent. I imagine that if we attach the
list of timestamps and/or hashes of recent update requests to each List column stored in Cassandra
we would be able to avoid applying duplicate updates. 
> * Explicitly document these operations as potentially unconsistent under these particular

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message