If I used consistency = ALL both when getting the record, and when saving the record, will that avoid the race condition?
On Sat, Nov 12, 2016 at 4:26 PM, Ali Akhtar <ali.rac...@gmail.com> wrote: > I'm responding to a 3rd party API, so I have no control over sending the > labels together instead of one by one. In this case, the API will send them > one by one. > > The list is actually of a list<frozen<my_udt>> and not a text (I used text > for simplification, apologies). > > In that case, will updates still merge the list values instead of > overwriting them? > > On Sat, Nov 12, 2016 at 4:15 PM, Oskar Kjellin <oskar.kjel...@gmail.com> > wrote: > >> Could you not send both labels in one request? Race conditions should >> still be handled as Vladimir suggests. But in this specific case the client >> could send both as 1 request thus simplifying the solution. >> >> /Oskar >> >> On 12 nov. 2016, at 12:05, Vladimir Yudovin <vla...@winguzone.com> wrote: >> >> Hi Ali, >> >> >What can I do so I end up with [1, 2] instead of either [1] or [2] after >> both requests have been processed? >> Use UPDATE, not INSERT. Thus new labels will be added to list, without >> overwriting old ones. Also consider usage of SET instead of LIST to avoid >> duplicates. >> >> Best regards, Vladimir Yudovin, >> >> *Winguzone <https://winguzone.com?from=list> - Hosted Cloud >> CassandraLaunch your cluster in minutes.* >> >> >> ---- On Sat, 12 Nov 2016 05:34:24 -0500*Ali Akhtar <ali.rac...@gmail.com >> <ali.rac...@gmail.com>>* wrote ---- >> >> I have a table where each record contains a list<string> 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? >> >> >> >
