Re: race condition for quorum consistency

2016-09-14 Thread Alexander Dejanovski
I haven't been very accurate in my first answer indeed, which was misleading. Apache Cassandra guarantees that if all queries are ran at least at quorum, a client writing successfully (as in the cluster acknowledged the write) then reading his previous write will see the correct value unless anothe

Re: race condition for quorum consistency

2016-09-14 Thread Tyler Hobbs
On Wed, Sep 14, 2016 at 3:49 PM, Nicolas Douillet < nicolas.douil...@gmail.com> wrote: > - > - during read requests, cassandra will ask to one node the data and to > the others involved in the CL a digest, and if all digests do not match, > will ask for them the entire data, handle the merge and f

Re: race condition for quorum consistency

2016-09-14 Thread Nicolas Douillet
Hi, In my opinion the guaranty provided by Cassandra is : if your write request in Quorum *succeed*, then the next (after the write response) read requests in Quorum (that succeed too) will be consistent (actually CL.Write + CL.Read > RF) Of course while you haven't received a valid r

Re: race condition for quorum consistency

2016-09-14 Thread Alexander Dejanovski
My understanding of the described scenario is that the write hasn't succeeded when reads are fired, as B and C haven't processed the mutation yet. There would be 3 clients here and not 2 : C1 writes, C2 and C3 read. So the race condition could still happen in this particular case. Le mer. 14 sep

Re: race condition for quorum consistency

2016-09-14 Thread Work
Hi Alex: Hmmm ... Assuming clock skew is eliminated And assuming nodes are up and available ... And assuming quorum writes and quorum reads and everyone waiting for success ( which is NOT The OP scenario), Two different clients will be guaranteed to see all successful writes, or be told tha

Re: race condition for quorum consistency

2016-09-14 Thread Alexander DEJANOVSKI
Hi, the analysis is valid, and strong consistency the Cassandra way means that one client writing at quorum, then reading at quorum will always see his previous write. Two different clients have no guarantee to see the same data when using quorum, as illustrated in your example. Only options here

race condition for quorum consistency

2016-09-14 Thread Qi Li
hi all, we are using quorum consistency, and we *suspect* there may be a race condition during the write. lets say RF is 3. so write will wait for at least 2 nodes to ack. suppose there is only 1 node acked(node A). the other 2 nodes(node B, C) are still waiting to update. there come two read requ