[
https://issues.apache.org/jira/browse/CASSANDRA-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784493#action_12784493
]
Kelvin Kakugawa commented on CASSANDRA-580:
-------------------------------------------
Ah, I see what you were going after. That's a more concise interface change.
My understanding about including a timestamp along w/ the logical clock is to
limit the potential growth of the vector. Basically, whenever a new node
updates a value, the vector size grows by one. However, the problem is that if
many different nodes happen to update a given value (for various
reasons--failure scenarios, etc.), the potential size of a vector could grow to
an unmanageable length and it would keep that length forever. So, the Dynamo
authors chose to tag each update with a timestamp, so they could truncate the
vector to only the last 10 nodes to update the value. There is a possibility
that an inconsistency could arise, because of the truncation. However, the
paper said in practice, it was a non-issue.
In summary, the timestamp is not there to help resolve consistency problems,
it's there to make the vector more manageable.
> vector clock support
> --------------------
>
> Key: CASSANDRA-580
> URL: https://issues.apache.org/jira/browse/CASSANDRA-580
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Environment: N/A
> Reporter: Kelvin Kakugawa
> Assignee: Kelvin Kakugawa
> Attachments: 580-interface-1-add-vector-clock.diff,
> 580-interface-2-add-vector-clock.diff, 580-thrift-v3.patch
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Allow a ColumnFamily to be versioned via vector clocks, instead of long
> timestamps. Purpose: enable incr/decr; flexible conflict resolution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
