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
>>>>>
>>>>
>>>>
>>>
>>
>

Reply via email to