Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id EE720200BBD for ; Tue, 25 Oct 2016 07:08:44 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id ED11C160B00; Tue, 25 Oct 2016 05:08:44 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id E88AE160AEB for ; Tue, 25 Oct 2016 07:08:43 +0200 (CEST) Received: (qmail 41466 invoked by uid 500); 25 Oct 2016 05:08:42 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 41455 invoked by uid 99); 25 Oct 2016 05:08:42 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Oct 2016 05:08:42 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id BAB8E180148 for ; Tue, 25 Oct 2016 05:08:41 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.379 X-Spam-Level: ** X-Spam-Status: No, score=2.379 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id SL9DBXDRa71e for ; Tue, 25 Oct 2016 05:08:39 +0000 (UTC) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 4C7525F576 for ; Tue, 25 Oct 2016 05:08:39 +0000 (UTC) Received: by mail-wm0-f53.google.com with SMTP id b80so140802900wme.1 for ; Mon, 24 Oct 2016 22:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1JI3FU6CUWj76u8/RivCTApGSh1Ja812dGN62bpoK08=; b=eDwv7eoj2injO/oZukLLWcpZ7486ztYGwgvxPS5fVsmCyyz6lieb/gygmR9WY0vTpk f8zUk9ObLf70zPz8OBHnaiO4a/9zfQBRARWx1hvz/iICszXufX6J/1o4NHxKrA1gjHbs oMTJ5ywPpcL8qouh4t+EvzP+a1leug54F+hqXq2hwD4LQi5PcGg6CQGjVIR+0exgV+4k Q4Fjsv7QanAEg9byNI4q69AZm3PFU5cpqrG2eVtVl7j9NDRd6iQ2YR+RaSyWkUMmOizz SSZK69X+OQIUssyQNH19lgUmFE8aszmWtv3pCPTuJ/7/hNcfmCyriDLrMnwOonjpCs5a J50Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1JI3FU6CUWj76u8/RivCTApGSh1Ja812dGN62bpoK08=; b=LBPAKKKllbGErahAO3t1C4yveJgivuXFpYo7m+1Ra35sY2XJl3jqy4jfzSgbc10fZQ bpnFm14i21eT/ztVg/ZdpWbdfXA/LqeiRdup7rp9/K9al9TWE9zBJ4UY7f91VnrIORKn Uk+eY0yHph4pwOEyTEM+6br5rfhTKMVvE7Y/W5k5CT1AR77kGKijIpPWkyJvULtbn8x6 OG5aYRiLy/IGkcNSCT5Zjj59G/VYaqEOHoWAlHTY7YrAF1RaRKEyieJSjMDZQuD8QoaM mBzvRBadF0hjOiSPDqFvMngPPWgElPcpnVC7knVrMwJu1TmccfYjwjzEXXNPh5lOU+2Z bnXw== X-Gm-Message-State: ABUngvf0QvHtxuq0C+QDvtScikblkOh4H5XtpaNSryVvkZjUcK9akojdSQK75gZjVjv2OpwyX/rK0PZU7zhwBw== X-Received: by 10.28.55.213 with SMTP id e204mr1027424wma.92.1477372117721; Mon, 24 Oct 2016 22:08:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.6.11 with HTTP; Mon, 24 Oct 2016 22:08:35 -0700 (PDT) Received: by 10.28.6.11 with HTTP; Mon, 24 Oct 2016 22:08:35 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Mickael_Delano=C3=AB?= Date: Tue, 25 Oct 2016 07:08:35 +0200 Message-ID: Subject: Re: Lightweight transaction inside a batch : request rejected To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11443abc47286a053fa980b2 archived-at: Tue, 25 Oct 2016 05:08:45 -0000 --001a11443abc47286a053fa980b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, I understand, thanks. So now i would like to know if there is some best practices to do what i want. I.e inserting entries in several tables (with same partition key) only if there is not already an entry in the main table. Keep in mind i wanted to do that inside a single batch because I can have 2 concurrent request trying to insert something different but with the same primary key in the main table. If i split the batch in 2 requests(1 with the LWT, 1 with the rest), how can i ensure the last batch won't override the previous data and that the whole data will be saved (in case of a problem between request1 and request2) ? Le 24 oct. 2016 12:47, "DuyHai Doan" a =C3=A9crit : "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 possible On Mon, Oct 24, 2016 at 11:34 AM, Mickael Delano=C3=AB wrote: > 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. Othe= r > 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 tab= les >> (even if same partition key) would require a lot of changes in the curre= nt >> 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=C3=AB >> 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 th= an >>> could be handled without problem. >>> Below is what I wanted to do. >>> >>> I am using cassandra 3.7. >>> >>> CREATE KEYSPACE test_ksp WITH replication =3D {'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; >>> >>> BEGIN BATCH >>> 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'); >>> APPLY BATCH; >>> >>> >>> 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 O= NE >>> condition on one table only. >>> I don't understand why cassandra returns an error "Batch with condition= s >>> 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 th= e >>> 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 execut= ed. >>> >>> Is there someone that could explain why this use case need to be >>> rejected by cassandra? And do you think this is something that cassandr= a >>> could handle in a future version ? >>> >>> Regards, >>> Micka=C3=ABl >>> >>> >> > > > -- > Micka=C3=ABl Delano=C3=AB > --001a11443abc47286a053fa980b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ok, I understand, thanks.
So now i would like to know if there is some best practices to do what i wa= nt.
I.e inserting entries in several tables (with same partition key) only if t= here is not already an entry in the main table.

Keep in mind i wanted to do that inside a single batch becau= se I can have 2 concurrent request trying to insert something different but= with the same primary key in the main table.

If i split the batch in 2 requests(1 with the LWT, 1 with th= e rest), how can i ensure the last batch won't override the previous da= ta and that the whole data will be saved (in case of a problem between requ= est1 and request2) ?


Le=C2=A024 oct. 2= 016 12:47, "DuyHai Doan" <doanduyhai@gmail.com> a =C3=A9crit=C2=A0:

=

"So I guess in that case the Paxos operation does no= t span multiple table but operates only the table that has the condition. A= m I wrong?"

--> The fact that you're using a BATCH with LWT mea= ns 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 possible
=

On Mon, Oct 24, 2= 016 at 11:34 AM, Mickael Delano=C3=AB <delanoemic@gmail.com> wrote:
Tha= nks 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 co= ndition on ONE table. Other statements of the batch does not have any condi= tion.
So I guess in that case the Paxos operation does not sp= an multiple table but operates only the table that has the condition. Am I = wrong?



2016-10-24 10:21 GMT+02:00 DuyHai Doan <doanduyhai@gmail.com= >:
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 p= artition key) would require a lot of changes in the current impl.

<= /div>
The question has already been raised, you may want to convince th= e committers by adding some comments here:=C2=A0https://issues.apa= che.org/jira/browse/CASSANDRA-10085

On Mon, Oct 24, 2016 at 9:58 AM, Mickael Delano=C3=AB <delanoemic@gmail.com> wrote:
Hi,

I would like to use lightweight transaction = inside a batch but the request is rejected by cassandra, however I think th= is 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 =3D {'class': 'SimpleStrategy', 'r= eplication_factor': '1'};

CREATE TABLE test_ksp.item (=C2=A0=C2=A0=C2=A0 user_id bigint,
=C2=A0=C2=A0=C2=A0 item_id text,=C2=A0=C2=A0=C2=A0 item_value text,
=C2=A0=C2=A0=C2=A0 item_key1 text,<= br>=C2=A0=C2=A0=C2=A0 item_key2 text,
PRIMARY KEY ((user_id), item_id));=

CREATE TABLE test_ksp.item_id_by_key (
=C2=A0=C2=A0=C2=A0 user_i= d bigint,
=C2=A0=C2=A0=C2=A0 item_key text,
=C2=A0=C2=A0=C2=A0 item_i= d text,
PRIMARY KEY ((user_id), item_key));

USE test_ksp;

= BEGIN BATCH
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, 'ke= y-ABC-789', 'i11');
APPLY BATCH;


So as you can se= e 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 un= derstand 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 ha= ve always the same partition key for every table inside the batch.
As th= ere is only one condition, I expected the paxos protocol just act on this c= ondition 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 partiti= on).
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 r= ejected by cassandra? And do you think this is something that cassandra cou= ld handle in a future version ?

Regards,
Micka=C3=ABl





--
Micka=C3=ABl Delano=C3=AB


--001a11443abc47286a053fa980b2--