[
https://issues.apache.org/jira/browse/CASSANDRA-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782276#action_12782276
]
Stu Hood edited comment on CASSANDRA-580 at 11/25/09 2:06 AM:
--------------------------------------------------------------
One important difference between Cassandra and some other systems utilizing
vector clocks is that in Cassandra, writes do not read from disk any old
versions of the value that is being written to. This means that conflict
resolution currently happens in 3 different places:
1. At read time - Two nodes have different versions,
2. At write time - The version being written is older than the version a node
has in a Memtable,
3. At compaction time - Versions of values persisted to different SSTables
disagree.
NB: For the purposes of this ticket, I think that all resolution should be
handled server side, deterministically, and that one of the following options
should be implemented as part of a separate ticket.
But before too much progress is made, we will probably want to decide whether
we want to support:
a) Client side conflict resolution (logic implemented on the client side),
b) Server side resolution (pluggable logic on the server),
c) A hybrid (pluggable resolution, which can optionally sends the versions to
the client at resolution time #1 or #2)
If we decide to implement client-side resolution (a), then we will need to
remove resolution at steps #2 and #3 (or make it optional for option (c)), and
keep more copies of the data. For #2, a Memtable could store conflicting
versions in memory until they are resolved by a read or flushed to disk. For
#3, SSTables will need to be able to store multiple versions of a row/cf until
they are resolved by a read.
was (Author: stuhood):
One important difference between Cassandra and some other systems utilizing
vector clocks is that in Cassandra, writes do not read from disk any old
versions of the value that is being written to. This means that conflict
resolution currently happens in 3 different places:
1. At read time - Two nodes have different versions,
2. At write time - The version being written is older than the version a node
has in a Memtable,
3. At compaction time - Versions of values persisted to different SSTables
disagree.
NB: For the purposes of this ticket, I think that all resolution should be
handled server side, deterministically, and that one of the following options
should be implemented as part of a separate ticket.
But before too much progress is made, we will probably want to decide whether
we want to support:
a) Client side conflict resolution (logic implemented on the client side),
b) Server side resolution (pluggable logic on the server),
c) A hybrid (pluggable resolution, which can optionally sends the versions to
the client at resolution time #1 or #2)
If we decide to implement client-side resolution (a), then we will need to
remove resolution at steps #2 and #3 (or make it optional for option (c)), and
keep more copies of the data. For #3, a Memtable could store conflicting
versions in memory until they are resolved by a read or flushed to disk. For
#2, SSTables will need to be able to store multiple versions of a row/cf until
they are resolved by a read.
> 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
> 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.
