oh, it would clarity a lot if you go to read the source code; the method is o.a.c.service.StorageProxy.fetchRows if I remember it correctly
On Wed, Oct 24, 2012 at 10:26 PM, Manu Zhang <owenzhang1...@gmail.com>wrote: > And we don't send read request to all of the three replicas (R1, R2, R3) > if CL=QUOROM; just 2 of them depending on proximity > > > On Wed, Oct 24, 2012 at 10:20 PM, Hiller, Dean <dean.hil...@nrel.gov>wrote: > >> The user will meet the required consistency unless you encounter some kind >> of bug in cassandra. You will either get the older value or the newer >> value. If you read quorum, and maybe a write CL=1 just happened, you may >> get the older or new value depending on if the node that received the >> write was involved. If you read quorum and your wrote CL=QUOROM, then you >> may get the newer value or the older value depending on who gets their >> first so to speak. >> >> In your scenario, if the read repair read from R2 just before the write is >> applied, you get the old value. If it read from R2 just after the write >> was applied, it gets the new value. BOTH of these met the consistency >> constraint. A better example to clear this up may be the following... If >> you read a value at CL=QUOROM, and you have a write 20ms later, you get >> the old value, right? And it met the consistency level, right? NOW, what >> about if the write is 1ms later? What if it the right is .00001ms later? >> It still met the consistency level, right? If it is .00001ms before, you >> get the new value as it repairs first with the new node. >> >> It is just when programming, your read may get the newer value or older >> value and generally if you write the code in a way that works, this >> concept works out great in most cases(in some cases, you need to think a >> bit differently and solve it other ways). >> >> I hope that clears it up >> >> Later, >> Dean >> >> On 10/24/12 8:02 AM, "shankarpnsn" <shankarp...@gmail.com> wrote: >> >> >Hiller, Dean wrote >> >> in general it is okay to get the older or newer value. If you are >> >>reading >> >> 2 rows however instead of one, that may change. >> > >> >This is certainly interesting, as it could mean that the user could see a >> >value that never met the required consistency. For instance with 3 >> >replicas >> ><R1,R2,R3> and a quorum consistency, assume that R1 is initiating a read >> >(becomes the coordinator) - notices a conflict with R2 (assume R1 has a >> >more >> >recent value) and initiates a read repair with its value. Meanwhile R2 >> and >> >R3 have seen two different writes with newer values than what was >> computed >> >by the read repair. If R1 were to respond back to the user with the value >> >that was computed at the time of read repair, wouldn't it be a value that >> >never met the consistency constraint? I was thinking if this should >> >trigger >> >another round of repair that tries to reach the consistency constraint >> >with >> >a newer value or time-out, which is the expected case when you don't meet >> >the required consistency. Please let me know if I'm missing something >> >here. >> > >> > >> > >> >-- >> >View this message in context: >> > >> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/What-does >> >-ReadRepair-exactly-do-tp7583261p7583366.html >> >Sent from the cassandra-u...@incubator.apache.org mailing list archive >> at >> >Nabble.com. >> >> >
