[ 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