cassandra-user mailing list archives

For single thread, consistency ALL it should work. I believe you do
something different. What are these three numbers exactly?
old=60616 val =19 new =60635
On Fri, Jan 10, 2014 at 1:50 PM, Manoj Khangaonkar <khangaonkar@gmail.com>wrote:
> Hi
>
> Using Cassandra 2.0.0.
> 3 node cluster
> Replication 2.
> Using consistency ALL for both read and writes.
>
> I have a single thread that reads a value, updates it and writes it back
> to the table. The column type is big int. Updating counts for a timestamp.
>
> With single thread and consistency ALL , I expect no lost updates. But as
> seem from my application log below,
>
> 10 07:01:58,507 [Thread-10] BeaconCountersCAS2DAO [INFO] 1389366000 H
> old=59614 val =252 new =59866
> 10 07:01:58,611 [Thread-10] BeaconCountersCAS2DAO [INFO] 1389366000 H
> old=59866 val =252 new =60118
> 10 07:01:59,136 [Thread-10] BeaconCountersCAS2DAO [INFO] 1389366000 H
> old=60118 val =255 new =60373
> 10 07:02:00,242 [Thread-10] BeaconCountersCAS2DAO [INFO] 1389366000 H
> old=60373 val =243 new =60616
> 10 07:02:00,244 [Thread-10] BeaconCountersCAS2DAO [INFO] 1389366000 H
> old=60616 val =19 new =60635
> 10 07:02:00,326 [Thread-10] BeaconCountersCAS2DAO [INFO] 1389366000 H
> old=60616 val =233 new =60849
>
> See the last 2 lines of above log.
> value 60116 is updated to 60635. but the next operation reads the old
> value 60616 again.
>
> I am not using counter column type because it does not support TTL and i
> hear there are lot of open issues with counters.
>
> Is there anything else I can do to further tighten the consistency or is
> this pattern of high volume read - update - write not going to work in C* ?
>
> regards
> MJ
>
> --
>
>