This might help you: https://github.com/edwardcapriolo/ec/blob/master/src/test/java/Base/CompareAndSwapTest.java
It counts using lwt's with multiple threads. On Fri, Sep 23, 2016 at 2:31 PM, Jaydeep Chovatia < chovatia.jayd...@gmail.com> wrote: > Since SERIAL consistency is not supported for batch updates, I used QUORUM > for the operation. > > On Fri, Sep 23, 2016 at 11:23 AM, DuyHai Doan <doanduy...@gmail.com> > wrote: > >> What is the consistency level used for the batch query ? >> >> >> On Fri, Sep 23, 2016 at 8:19 PM, Jaydeep Chovatia < >> chovatia.jayd...@gmail.com> wrote: >> >>> Ok. But I am trying to understand a scenario under which this mis-match >>> can occur with light-weight tx. >>> >>> On Fri, Sep 23, 2016 at 11:14 AM, DuyHai Doan <doanduy...@gmail.com> >>> wrote: >>> >>>> Lightweight transaction is not available for counters, for the simple >>>> reason that counters are not idempotent >>>> >>>> On Fri, Sep 23, 2016 at 8:10 PM, Jaydeep Chovatia < >>>> chovatia.jayd...@gmail.com> wrote: >>>> >>>>> We have a following table: >>>>> >>>>> create table mytable { >>>>> >>>>> id int, >>>>> count int static, >>>>> rec_id int, >>>>> primary key (id, rec_id) >>>>> >>>>> }; >>>>> >>>>> The count in the table represents how many records (rec_id clustering >>>>> columns) exists. So when we add new a new record we do it following way: >>>>> >>>>> UNLOGGED BATCH >>>>> insert into mytable (id, rec_id) values (<id>, <rec_id>); >>>>> update mytable set count = <read_count> + 1 where id = <id> if count = >>>>> <read_count>; //light-weight transaction >>>>> APPLY BATCH >>>>> >>>>> Then we do following read query as QUORUM: >>>>> >>>>> select count, rec_id from mytable where id = <id>; >>>>> >>>>> Here we expect count to exactly match number of rows (number of >>>>> clustering rec_id) returned. But under a stress we have observed that they >>>>> do not match sometimes. >>>>> >>>>> Is this expected? >>>>> >>>>> Thanks, >>>>> Jaydeep >>>>> >>>> >>>> >>> >> >