[CASSANDRA-4806] Consistency of Append/Prepend on Lists need to be improved or clarified

• Type: Improvement
• Status: Resolved
• Priority: Low
• Resolution: Fixed
• Fix Version/s: 1.2.0
• Assignee: Sylvain Lebresne
• Reporter: Michaël Figuière

Authors

Sylvain Lebresne

• Created: 15/Oct/12 12:18
• Updated: 16/Apr/19 09:32
• Resolved: 23/Nov/12 14:37

Description

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.