Re: Lightweight tx is good enough to handle counter?

[Edward Capriolo]

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 
> 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 
>>> 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 (, );
> update mytable set count =  + 1 where id =  if count =
> ; //light-weight transaction
> APPLY BATCH
>
> Then we do following read query as QUORUM:
>
> select count, rec_id from mytable where 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
>


>>>
>>
>

Re: Lightweight tx is good enough to handle counter?

[Jaydeep Chovatia]

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  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 
>> 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 (, );
 update mytable set count =  + 1 where id =  if count =
 ; //light-weight transaction
 APPLY BATCH

 Then we do following read query as QUORUM:

 select count, rec_id from mytable where 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

>>>
>>>
>>
>

Re: Lightweight tx is good enough to handle counter?

[DuyHai Doan]

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 
> 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 (, );
>>> update mytable set count =  + 1 where id =  if count =
>>> ; //light-weight transaction
>>> APPLY BATCH
>>>
>>> Then we do following read query as QUORUM:
>>>
>>> select count, rec_id from mytable where 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
>>>
>>
>>
>

Re: Lightweight tx is good enough to handle counter?

[Jaydeep Chovatia]

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  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 (, );
>> update mytable set count =  + 1 where id =  if count =
>> ; //light-weight transaction
>> APPLY BATCH
>>
>> Then we do following read query as QUORUM:
>>
>> select count, rec_id from mytable where 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
>>
>
>

Re: Lightweight tx is good enough to handle counter?

[DuyHai Doan]

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 (, );
> update mytable set count =  + 1 where id =  if count =
> ; //light-weight transaction
> APPLY BATCH
>
> Then we do following read query as QUORUM:
>
> select count, rec_id from mytable where 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
>