Michaël Figuière created CASSANDRA-4806:
-------------------------------------------
Summary: Consistency of Append/Prepend on Lists need to be
improved or clarified
Key: CASSANDRA-4806
URL: https://issues.apache.org/jira/browse/CASSANDRA-4806
Project: Cassandra
Issue Type: Improvement
Reporter: Michaël Figuière
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 conditions.
--
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: http://www.atlassian.com/software/jira
