[
https://issues.apache.org/jira/browse/CASSANDRA-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4806:
--------------------------------------
Priority: Minor (was: Major)
Affects Version/s: 1.2.0 beta 1
Fix Version/s: 1.2.0 beta 2
Assignee: Sylvain Lebresne
I thought we were going with (3) but open to solutions.
> 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
