Without commenting on the other parts of the design, this part is not possible "attempts to
add to a dead counter throws an exception "
All write operations are no look operations (write to the log, update memtables) we never
look at the SSTables. It goes against the architecture of the write path to require a read
from disk.
Cheers
-----------------
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 29 May 2011, at 20:04, Yang wrote:
>
> sorry in the notation, instead of "ttl" I mean "timestamp"
>
>
> On Sun, May 29, 2011 at 12:24 AM, Yang <teddyyyy123@gmail.com> wrote:
> sorry to beat on the dead horse.
>
> I looked at the link referred from #2103 : https://issues.apache.org/jira/browse/CASSANDRA-2101
> I agree with the reasoning in #2101 that the ultimate issue is that delete and counter
adds are not commutative. since by definition we can't achieve
> predictable behavior with deletes + counter, can we redefine the behavior of counter
deletes, so that we can always guarantee the declared behavior? --- specifically:
>
>
> we define that once a counter column is deleted, you can never add to it again. attempts
to add to a dead counter throws an exception ---- all future adds are just ignored. i.e.
a counter column has only one life, until all tombstones are purged from system, after which
it is possible for the counter to have a new incarnation. basically instead of solving the
problem raised in #2103, we declare openly that it's unsolvable (which is true), and make
the code reflect this fact.
>
>
>
> I think this behavior would satisfy most use cases of counters. so instead of relying
on the advice to developers: "do not do updates for a period after deletes, otherwise it probably
wont' work", we enforce this into the code.
>
>
> the same logic can be carried over into expiring column, since they are essentially automatically
inserted deletes. that way #2103 could be "solved"
>
>
> I'm attaching an example below, you can refer to them if needed.
>
> Thanks a lot
> Yang
>
>
> example:
> for simplicity we assume there is only one column family , one column, so we omit column
name and cf name in our notation, assume all counterColumns have a delta value of 1, we only
mark their ttl now. so c(123) means a counter column of ttl=1, adding a delta of 1. d(456)
means a tombstone with ttl=456.
>
> then we can have the following operations
>
> operation result after operation
> ----------------------------------------------------------------------
> c(1) count=1
> d(2) count = null ( counter not present )
> c(3) count = null ( add on dead counter ignored)
> ---------------------------------------------------
>
>
> if the 2 adds arrive out of order , we would still guarantee eventual consistency:
>
> operation result after operation
> --------------------------------------------------------------------------------
> c(1) count=1
> c(3) count=2 (we have 2 adds, each with delta=1)
> d(2) count=null (deleted)
> --------------------------------------------------------------
> at the end of both scenarios, the result is guaranteed to be null;
> note that in the second scenario, line 2 shows a snapshot where we have a state with
count=2, which scenario 1 never sees this. this is fine, since even regular columns can have
this situation (just consider if the counter columns were inserts/overwrites instead )
>
>
>
> On Fri, May 27, 2011 at 5:57 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
> > No. See comments to https://issues.apache.org/jira/browse/CASSANDRA-2103
> >
> > On Fri, May 27, 2011 at 7:29 PM, Yang <teddyyyy123@gmail.com> wrote:
> >> is this combination feature available , or on track ?
> >>
> >> thanks
> >> Yang
> >>
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder of DataStax, the source for professional Cassandra support
> > http://www.datastax.com
> >
>
>
|