I don't think that's bulletproof either.  For instance, what if the
two adds go to replica 1 but the delete to replica 2?

Bottom line (and this was discussed on the original
delete-for-counters ticket,
https://issues.apache.org/jira/browse/CASSANDRA-2101), counter deletes
are not fully commutative which makes them fragile.

On Mon, Jun 13, 2011 at 10:54 AM, Yang <teddyyyy...@gmail.com> wrote:
> as https://issues.apache.org/jira/browse/CASSANDRA-2101
> indicates, the problem with counter delete is  in scenarios like the
> following:
> add 1, clock 100
> delete , clock 200
> add  2 , clock 300
> if the 1st and 3rd operations are merged in SStable compaction, then we
> have
> delete  clock 200
> add 3,  clock 300
> which shows wrong result.
>
> I think a relatively simple extension can be used to complete fix this
> issue: similar to ZooKeeper, we can prefix an "Epoch" number to the clock,
> so that
>    1) a delete operation increases future epoch number by 1
>    2) merging of delta adds can be between only deltas of the same epoch,
> deltas of older epoch are simply ignored during merging. merged result keeps
> the epoch number of the newest seen.
> other operations remain the same as current. note that the above 2 rules are
> only concerned with merging within the deltas on the leader, and not related
> to the replicated count, which is a simple final state, and observes the
> rule of "larger clock trumps". naturally the ordering rule is: epoch1.clock1
>> epoch2.clock2  iff epoch1 > epoch2 || epoch1 == epoch2 && clock1 > clock2
> intuitively "epoch" can be seen as the serial number on a new "incarnation"
> of a counter.
>
> code change should be mostly localized to CounterColumn.reconcile(),
>  although, if an update does not find existing entry in memtable, we need to
> go to sstable to fetch any possible epoch number, so
> compared to current write path, in the "no replicate-on-write" case, we need
> to add a read to sstable. but in the "replicate-on-write" case, we already
> read that, so it's no extra time cost.  "no replicate-on-write" is not a
> very useful setup in reality anyway.
>
> does this sound a feasible way?   if this works, expiring counter should
> also naturally work.
>
> Thanks
> Yang



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Reply via email to