If I used consistency = ALL both when getting the record, and when saving the record, will that avoid the race condition?
If I use consistency level = all, will that cause it to end up with [1,2]? No. Even if you have only one host it's possible that two threads first both read data and than overwrite existing value 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? Do you mean UPDATE cql operation? Yes, it adds new values to list, allowing duplicates. 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. As I mentioned duplicates are allowed in LIST, and as DOC says: These update operations are implemented internally without any read-before-write. Appending and prepending a new element to the list writes only the new element. Only when using index When you add an element at a particular position, Cassandra reads the entire list, and then writes only the updated element. Consequently, adding an element at a particular position results in greater latency than appending or prefixing an element to a list. Best regards, Vladimir Yudovin, Winguzone - Hosted Cloud Cassandra Launch your cluster in minutes. ---- On Sat, 12 Nov 2016 07:57:36 -0500Ali Akhtar <ali.rac...@gmail.com> wrote ---- The labels collection is of the type set<frozen<label>> , where label is a udt containing: id, name, description , all text fields. On Sat, Nov 12, 2016 at 5:54 PM, Ali Akhtar <ali.rac...@gmail.com> wrote: The problem isn't just the update / insert though, right? Don't frozen entities get overwritten completely? So if I had [1] [2] being written as updates, won't each update overwrite the set completely, so i'll end up with either one of them instead of [1,2]? On Sat, Nov 12, 2016 at 5:50 PM, DuyHai Doan <doanduy...@gmail.com> wrote: Maybe you should use my Achilles mapper, which does generates UPDATE statements on collections and not only INSERT Le 12 nov. 2016 13:08, "Ali Akhtar" <ali.rac...@gmail.com> a écrit : 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?
