You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Jaydeep Chovatia <ch...@gmail.com> on 2016/09/23 18:10:08 UTC
Lightweight tx is good enough to handle counter?
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
Re: Lightweight tx is good enough to handle counter?
Posted by Edward Capriolo <ed...@gmail.com>.
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.jaydeep@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 <do...@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.jaydeep@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 <do...@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.jaydeep@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
>>>>>
>>>>
>>>>
>>>
>>
>
Re: Lightweight tx is good enough to handle counter?
Posted by Jaydeep Chovatia <ch...@gmail.com>.
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 <do...@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.jaydeep@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 <do...@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.jaydeep@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
>>>>
>>>
>>>
>>
>
Re: Lightweight tx is good enough to handle counter?
Posted by DuyHai Doan <do...@gmail.com>.
What is the consistency level used for the batch query ?
On Fri, Sep 23, 2016 at 8:19 PM, Jaydeep Chovatia <
chovatia.jaydeep@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 <do...@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.jaydeep@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
>>>
>>
>>
>
Re: Lightweight tx is good enough to handle counter?
Posted by Jaydeep Chovatia <ch...@gmail.com>.
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 <do...@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.jaydeep@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
>>
>
>
Re: Lightweight tx is good enough to handle counter?
Posted by DuyHai Doan <do...@gmail.com>.
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.jaydeep@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
>