[
https://issues.apache.org/jira/browse/CASSANDRA-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13476806#comment-13476806
]
Sylvain Lebresne commented on CASSANDRA-4806:
---------------------------------------------
(2) doesn't work in general for the same reason than for counters, i.e. in
general we cannot guarantee a retry will hit the same replica than the initial
write. It would also require a read during the write, which we haven't for
append/prepend.
So unless someone else has a much better idea I think it's either (1) if we
consider that the danger of the lack of idempotence is greater than the
benefits of having lists (removing append/prepend is equivalent to removing the
lists) or (3), which also has my preference. So if no one objects, I'll just
document that whenever I'll update the CQL3 ref doc for collections (it's
somewhere on my todo list but it hasn't been done yet).
> 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
> 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 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
