Hi Garvit, I can not answer your main question but when I read your lines one thing was popping up constantly: "why do you ask this?"
So what is the background of this question? Do you see anything smelly? Actually a) I always assumed so naturally there are of course lots of in-parallel activities (writes) against any tables includin counters. So of course there is a race condition and probably threads yes b) Cassandra do not have isolated transactions so of course in a complex flow (using multiple tables) there is no business data consistency guarantee for sure c) until you are doing just +/- ops it is a mathematical fact that execution order of writes is not really important. Repeating +1 increase 5 times will result in higher counter by num 5... Please share your background I am interested in it! Cheers Attila 2019. máj. 29., Sze 2:34 dátummal Garvit Sharma <garvit...@gmail.com> ezt írta: > Hi, > > I am using counter tables in Cassandra and I want to understand how the > concurrent updates to counter table are handled in Cassandra. > > There are more than one threads who are responsible for updating the > counter for a partition key. Multiple threads can also update the counter > for the same key. > > In case when more than one threads updating the counter for the same key, > how Cassandra is handling the race condition? > > UPDATE cycling.popular_count > SET popularity = popularity + 1 > WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47; > > > Are there overheads of using counter tables? > Are there alternatives to counter tables? > > Thanks, > -- > > Garvit Sharma > github.com/garvitlnmiit/ > > No Body is a Scholar by birth, its only hard work and strong determination > that makes him master. >
