cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DuyHai Doan <>
Subject Re: Lightweight transaction inside a batch : request rejected
Date Mon, 24 Oct 2016 10:46:51 GMT
"So I guess in that case the Paxos operation does not span multiple table
but operates only the table that has the condition. Am I wrong?"

--> The fact that you're using a BATCH with LWT means that either ALL
statements succeed or NONE. And to guarantee this, Paxos ballot must cover
all statements. In your case since they span on multiple tables it's not

On Mon, Oct 24, 2016 at 11:34 AM, Mickael Delanoë <>

> Thanks DuyHai for the info.
> I already see this JIRA, however the use case I describe is slightly
> different from the JIRA as there is only ONE condition on ONE table. Other
> statements of the batch does not have any condition.
> So I guess in that case the Paxos operation does not span multiple table
> but operates only the table that has the condition. Am I wrong?
> 2016-10-24 10:21 GMT+02:00 DuyHai Doan <>:
>> As far as I remember, there is an optimization in Cassandra to manage
>> Paxos ballot per table. So asking a Paxos operation to span multiple tables
>> (even if same partition key) would require a lot of changes in the current
>> impl.
>> The question has already been raised, you may want to convince the
>> committers by adding some comments here: https://issues.apache.or
>> g/jira/browse/CASSANDRA-10085
>> On Mon, Oct 24, 2016 at 9:58 AM, Mickael Delanoë <>
>> wrote:
>>> Hi,
>>> I would like to use lightweight transaction inside a batch but the
>>> request is rejected by cassandra, however I think this is a use case than
>>> could be handled without problem.
>>> Below is what I wanted to do.
>>> I am using cassandra 3.7.
>>> CREATE KEYSPACE test_ksp WITH replication = {'class': 'SimpleStrategy',
>>> 'replication_factor': '1'};
>>> CREATE TABLE test_ksp.item (
>>>     user_id bigint,
>>>     item_id text,
>>>     item_value text,
>>>     item_key1 text,
>>>     item_key2 text,
>>> PRIMARY KEY ((user_id), item_id));
>>> CREATE TABLE test_ksp.item_id_by_key (
>>>     user_id bigint,
>>>     item_key text,
>>>     item_id text,
>>> PRIMARY KEY ((user_id), item_key));
>>> USE test_ksp;
>>> INSERT INTO item (user_id, item_id, item_value, item_key1, item_key2)
>>> values (1,'i11','item-C', 'key-XYZ-123', 'key-ABC-789') IF NOT EXISTS;
>>> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
>>> 'key-XYZ-123', 'i11');
>>> INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1,
>>> 'key-ABC-789', 'i11');
>>> So as you can see this is a batch that targets 2 tables but with the
>>> same partition key (i.e the same target nodes). Moreover It uses only ONE
>>> condition on one table only.
>>> I don't understand why cassandra returns an error "Batch with conditions
>>> cannot span multiple tables" in that case.
>>> I understand that if I had used several conditions on different tables
>>> it could be a problem, but in my case there is only one condition and
>>> moreover I have always the same partition key for every table inside the
>>> batch.
>>> As there is only one condition, I expected the paxos protocol just act
>>> on this condition and as the partition keys are all the same, the paxos
>>> protocol has only to work with the same replica nodes (not span across
>>> multiple partition).
>>> In my point of view this is as if the LWT was in a single statement,
>>> except that after the LWT is accepted a complete batch has to be executed.
>>> Is there someone that could explain why this use case need to be
>>> rejected by cassandra? And do you think this is something that cassandra
>>> could handle in a future version ?
>>> Regards,
>>> Mickaël
> --
> Mickaël Delanoë

View raw message