Ahh forgot to mention we have RF=2, sorry! LWT requires RF >= 3 otherwise we can not tolerate losing a node (because of LOCAL_QUORUM is working in the background which you can not really change AFAIK...)
Or am I wrong? Plus in a highly concurrent setup writing the same PK this optimistic locking fashion would end up in lots of retries I'm afraid. Eventually making this strategy much more expensive. Or am I wrong here too? Cheers Attila On Sun, 7 Mar 2021, 05:20 Jeff Jirsa, <[email protected]> wrote: > > You can do this with conditional (CAS) updates - update ... set c=y if c=x > > Requires serial writes and serial reads, so a bit more expensive, but > allows TTL. > > > On Mar 6, 2021, at 8:03 AM, Attila Wind <[email protected]> wrote: > > > > Hi guys, > > We do use Counter tables a lot because in our app we have several things > to count (business logic) > > More time we work with Cassandra we keep hearing more and more: "you > should not use counter tables because ....." > Yes, we also feel here and there the trade off is too much restrictive - > for us what hurts now days is that deleting counters it seems not that > simple... Also the TTL possibility we do miss a lot. > > But I have to confess I do not see an obvious migration strategy here... > What bothers me e.g.: concurrency, and wrong results thanks to that > namely > > If I want to fulfill the mission "UPDATE table SET mycounter = mycounter + > x WHERE ..." does > with traditional table (with an int column) I need to do this: > 1. read the value of "mycounter" > 2. add x to the value I readc(in memory) > 3. update mycounter = new value > > Needless to say that if I have a race condition so ThreadA and ThreadB are > executing the above sequence ~ the same time then the mycounter value will > be wrong... > > I started to wonder: how do you solve this problem? > Is anyone aware of any nice post/article regarding migration strategy - > stepping away from counters? > > thanks! > > > -- > Attila Wind > > http://www.linkedin.com/in/attilaw > Mobile: +49 176 43556932 > > >
