I am using the Java Cassandra mapper for all of these cases, so my code looks like this:
Item myItem = myaccessor.get( itemId ); Mapper<Item> mapper = mappingManager.create( Item.class ); myItem.labels.add( newLabel ); mapper.save( myItem ); On Sat, Nov 12, 2016 at 5:06 PM, Ali Akhtar <ali.rac...@gmail.com> wrote: > 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 <doanduy...@gmail.com> wrote: > >> Don't use list, use set instead. If you need ordering of insertion, use a >> map<timeuuid,text> 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 <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? >>> >> >> >
