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 A197B200BB8 for ; Sat, 12 Nov 2016 13:06:15 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id A0104160B00; Sat, 12 Nov 2016 12:06:15 +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 C569F160AF4 for ; Sat, 12 Nov 2016 13:06:14 +0100 (CET) Received: (qmail 48690 invoked by uid 500); 12 Nov 2016 12:06:13 -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 48680 invoked by uid 99); 12 Nov 2016 12:06:13 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Nov 2016 12:06:13 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id CE39AC50F3 for ; Sat, 12 Nov 2016 12:06:12 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.629 X-Spam-Level: ** X-Spam-Status: No, score=2.629 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id dahC09PmLgYj for ; Sat, 12 Nov 2016 12:06:11 +0000 (UTC) Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id CF3885F254 for ; Sat, 12 Nov 2016 12:06:10 +0000 (UTC) Received: by mail-wm0-f42.google.com with SMTP id g23so21987904wme.1 for ; Sat, 12 Nov 2016 04:06:10 -0800 (PST) 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=oTfx+lQmvb8uQEY9wS+AhPyMQ477Vb+f57ccH4VotQU=; b=XC87V9uJPfW3OtIGbEuj9JqKZOA82BL/puluMc+loFg9v3kOj8h/5cVjC+XmZ2NZEx N4D80pAwcdYNfcQvr8GaPtpFUl8BSHhwZa3TtywoCbH9q7RNGn7h3JJACAzVisqtXkw0 bV6W09sOmpi7Lbhl8RPnaP9JI4Vcm+gHlWwzLwJpOHwH223URMiq3jBWdKs5h1OxgzvO 2o2WKemPFy0YRjDTfEdwewT5ysLKYJXpsEI+6ZFlbMkk0L3DcpLIRUF+II0/CfOLbkEA vpyzsJuKTeZD3AN9BymBPnsBTeMFMNLZK8xRx3uXsBq4M4EBITnaS8/WfUn8xityYg83 Br2w== 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=oTfx+lQmvb8uQEY9wS+AhPyMQ477Vb+f57ccH4VotQU=; b=TaSgSOo8ULCwfkiUc9WtIHMX9IBtVrbv7hzJk3blQDl20fjLZOZbr3wFlXHDz2+5r/ Va8Kt089MKr+KFfi0svvLgCiscfbvipRT2NboSZTX3L7xPQz6k1GPI52ORXX7IV2TQFO tA//MSXSFy47R9qVE/WDP4xk4NMcpA8DAoLAVJ9QJeaUJF34JUEqWmV6+CUqMvwnTwSK 9jefx2i56MQlHAYEyvRvKEClVJoptLgqKbU4bj7B9CGb+WaHuDo+P5oDRuNPF1Cu7P34 iqMzNXOITH80rPiDDSsAj8IM7lZCikKQFUgHrtIE5GVz3dutn7W9CCSFB45r6sqc7oYb XIrA== X-Gm-Message-State: ABUngvfJpzdg1lramxfPgViWnW289EgHQ1IJ8L21ZLEyYGejs6xy+/nEvmbkjTfiKORj6pbbgFo1PqqQIbrNHw== X-Received: by 10.194.43.73 with SMTP id u9mr12421719wjl.109.1478952364465; Sat, 12 Nov 2016 04:06:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.50.197 with HTTP; Sat, 12 Nov 2016 04:06:03 -0800 (PST) In-Reply-To: References: From: Ali Akhtar Date: Sat, 12 Nov 2016 17:06:03 +0500 Message-ID: Subject: Re: Consistency when adding data to collections concurrently? To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=047d7b67050352ede90541196ecd archived-at: Sat, 12 Nov 2016 12:06:15 -0000 --047d7b67050352ede90541196ecd Content-Type: text/plain; charset=UTF-8 Thanks DuyHai, I will switch to using a set. But I'm still not sure how to resolve the original question. - Original labels = [] - Request 1 arrives with label = 1, and request 2 arrives with label = 2 - Updates are sent to c* with labels = [1] and labels = [2] simultaneously. What will happen in the above case? Will it cause the labels to end up as [1,2] (what I want) or either [1] or [2]? If I use consistency level = all, will that cause it to end up with [1,2]? On Sat, Nov 12, 2016 at 4:59 PM, DuyHai Doan wrote: > Don't use list, use set instead. If you need ordering of insertion, use a > map where timeuuid is generated by the client to guarantee > insertion order > > When setting a new value to a list, C* will do a read-delete-write > internally e.g. read the current list, remove all its value (by a range > tombstone) and then write the new list. Please note that prepend & append > operations on list do not require this read-delete-write and thus performs > slightly better > > On Sat, Nov 12, 2016 at 11:34 AM, Ali Akhtar wrote: > >> I have a table where each record contains a list of labels. >> >> I have an endpoint which responds to new labels being added to a record >> by the user. >> >> Consider the following scenario: >> >> - Record X, labels = [] >> - User selects 2 labels, clicks a button, and 2 http requests are >> generated. >> - The server receives request for Label 1 and Label 2 at the same time. >> - Both requests see the labels as empty, add 1 label to the collection, >> and send it. >> - Record state as label 1 request sees it: [1], as label 2 sees it: [2] >> >> How will the above conflict be resolved? What can I do so I end up with >> [1, 2] instead of either [1] or [2] after both requests have been processed? >> > > --047d7b67050352ede90541196ecd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0DuyHai, I will switch to using a set.

=
But I'm still not sure how to resolve the original question.=

- Original labels =3D []
- Request 1 ar= rives with label =3D 1, and request 2 arrives with label =3D 2
- = Updates are sent to c* with labels =3D [1] and labels =3D [2] simultaneousl= y.

What will happen in the above case? Will it cau= se the labels to end up as [1,2] (what I want) or either [1] or [2]?
<= div>
If I use consistency level =3D all, will that cause it t= o end up with [1,2]?

On Sat, Nov 12, 2016 at 4:59 PM, DuyHai Doan <doanduyh= ai@gmail.com> wrote:
Don't use list, use set instead. If you need ordering of ins= ertion, use a map<timeuuid,text> where timeuuid is generated by the c= lient to guarantee insertion order

When setting a new va= lue to a list, C* will do a read-delete-write internally e.g. read the curr= ent list, remove all its value (by a range tombstone) and then write the ne= w list. Please note that prepend & append operations on list do not req= uire this read-delete-write and thus performs slightly better

On Sat, Nov 12, 2016 at 11:34 AM, Ali Akhtar <ali.= rac200@gmail.com> wrote:
I have a table where each record contains a list<string&g= t; of labels.

I have an endpoint which responds to new l= abels being added to a record by the user.

Conside= r the following scenario:

- Record X, labels =3D [= ]
- User selects 2 labels, clicks a button, and 2 http requests a= re generated.
- The server receives request for Label 1 and Label= 2 at the same time.
- Both requests see the labels as empty, add= 1 label to the collection, and send it.
- Record state as label = 1 request sees it: [1], as label 2 sees it: [2]

Ho= w will the above conflict be resolved? What can I do so I end up with [1, 2= ] instead of either [1] or [2] after both requests have been processed?


--047d7b67050352ede90541196ecd--