On Thu, Feb 24, 2011 at 6:01 PM, Anthony John <chirayit...@gmail.com> wrote:
> If you are correct and you are probably closer to the code - then CL of > Quorum does not guarantee a consistency. If the operation succeed, it does (for some definition of consistency which is, following reads at Quorum will be guaranteed to see the new value of a update at quorum). If it fails, then no, it does not guarantee consistency. It is important to note that the word consistency has multiple meaning. In particular, when we are talking of consistency in Cassandra, we are not talking of the same definition as the C in ACID (see: http://www.allthingsdistributed.com/2007/12/eventually_consistent.html) > > On Thu, Feb 24, 2011 at 10:54 AM, Sylvain Lebresne > <sylv...@datastax.com>wrote: > >> On Thu, Feb 24, 2011 at 5:34 PM, Anthony John <chirayit...@gmail.com>wrote: >> >>> >>Time stamps are not used for conflict resolution - unless is is part >>>> of the application logic!!! >>>> >>> >>> >>What is you definition of conflict resolution ? Because if you update >>> twice the same column (which >>> >>I'll call a conflict), then the timestamps are used to decide which >>> update wins (which I'll call a resolution). >>> >>> I understand what you are saying, and yes semantics is very important >>> here. And yes we are responding to the immediate questions without covering >>> all questions in the thread. >>> >>> The point being made here is that the timestamp of the column is not used >>> by Cassandra to figure out what data to return. >>> >> >> Not quite true. >> >> >>> E.g. - Quorum is 2 nodes - and RF of 3 over N1/2/3 >>> A Quorum Write comes and add/updates the time stamp (TS2) of a >>> particular data element. It succeeds on N1 - fails on N2/3. So the write is >>> returned as failed - right ? >>> Now Quorum read comes in for exactly the same piece of data that the >>> write failed for. >>> So N1 has TS2 but both N2/3 have the old TS (say TS1) >>> And the read succeeds - Will it return TS1 or TS2. >>> >>> I submit it will return TS1 - the old TS. >>> >> >> It all depends on which (first 2) nodes respond to the read (since RF=3, >> that can any two of N1/N2/N3). If N1 is part of the two that makes the >> quorum, then TS2 will be returned, because cassandra will compare the >> timestamp and decide what to return based on this. If N2/N3 responds >> however, both timestamp will be TS1 and so, after timestamp resolution, it >> will stil be TS1 that will be returned. >> So yes timestamp is used for conflict resolution. >> >> In your example, you could get TS1 back because a failed write can let you >> cluster in an inconsistent state. You'd have to retry the quorum and only >> when it succeeds can you be guaranteed that quorum read will always return >> TS2. >> >> This is because when a write fails, Cassandra doesn't guarantee that the >> write did not made it in (there is no revert). >> >> >>> >>> Are we on the same page with this interpretation ? >>> >>> Regards, >>> >>> -JA >>> >>> On Thu, Feb 24, 2011 at 10:12 AM, Sylvain Lebresne <sylv...@datastax.com >>> > wrote: >>> >>>> On Thu, Feb 24, 2011 at 4:52 PM, Anthony John <chirayit...@gmail.com>wrote: >>>> >>>>> Sylvan, >>>>> >>>>> Time stamps are not used for conflict resolution - unless is is part of >>>>> the application logic!!! >>>>> >>>> >>>> What is you definition of conflict resolution ? Because if you update >>>> twice the same column (which >>>> I'll call a conflict), then the timestamps are used to decide which >>>> update wins (which I'll call a resolution). >>>> >>>> >>>>> You can have "lost updates" w/Cassandra. You need to to use 3rd >>>>> products - cages for e.g. - to get ACID type consistency. >>>>> >>>> >>>> Then again, you'll have to define what you are calling "lost updates". >>>> Provided you use a reasonable consistency level, Cassandra provides fairly >>>> strong durability guarantee, so for some definition you don't "lose >>>> updates". >>>> >>>> That being said, I never pretended that Cassandra provided any ACID >>>> guarantee. ACID relates to transaction, which Cassandra doesn't support. If >>>> we're talking about the guarantees of transaction, then by all means, >>>> cassandra won't provide it. And yes you can use cages or the like to get >>>> transaction. But that was not the point of the thread, was it ? The thread >>>> is about vector clocks, and that has nothing to do with transaction (vector >>>> clocks certainly don't give you transactions). >>>> >>>> Sorry if I wasn't clear in my mail, but I was only responding to why so >>>> far I don't think vector clocks would really provide much for Cassandra. >>>> >>>> -- >>>> Sylvain >>>> >>>> >>>>> -JA >>>>> >>>>> >>>>> On Thu, Feb 24, 2011 at 7:41 AM, Sylvain Lebresne < >>>>> sylv...@datastax.com> wrote: >>>>> >>>>>> On Thu, Feb 24, 2011 at 3:22 AM, Anthony John >>>>>> <chirayit...@gmail.com>wrote: >>>>>> >>>>>>> Apologies : For some reason my response on the original mail keeps >>>>>>> bouncing back, thus this new one! >>>>>>> > From the other hand, the same article says: >>>>>>> > "For conditional writes to work, the condition must be evaluated at >>>>>>> all update >>>>>>> > sites before the write can be allowed to succeed." >>>>>>> > >>>>>>> > This means, that when doing such an update CL=ALL must be used >>>>>>> >>>>>>> Sorry, but I am confused by that entire thread! >>>>>>> >>>>>>> Questions:- >>>>>>> 1. Does Cassandra implement any kind of data locking - at any >>>>>>> granularity whether it be row/colF/Col ? >>>>>>> >>>>>> >>>>>> No locking, no. >>>>>> >>>>>> >>>>>>> 2. If the answer to 1 above is NO! - how does CL ALL prevent >>>>>>> conflicts. Concurrent updates on exactly the same piece of data on >>>>>>> different >>>>>>> nodes can still mess each other up, right ? >>>>>>> >>>>>> >>>>>> Not sure why you are taking CL.ALL specifically. But in any CL, >>>>>> updating the same piece of data means the same column value. In that >>>>>> case, >>>>>> the resolution rules are the following: >>>>>> - If the updates have a different timestamp, keep the one with the >>>>>> higher timestamp. That is, the more recent of two updates win. >>>>>> - It the timestamps are the same, then it compares the values (byte >>>>>> comparison) and keep the highest value. This is just to break ties in a >>>>>> consistent manner. >>>>>> >>>>>> So if you do two truly concurrent updates (that is from two place at >>>>>> the same instant), then you'll end with one of the update. This is the >>>>>> column level. >>>>>> >>>>>> However, if that simple conflict detection/resolution mechanism is not >>>>>> good enough for some of your use case and you need to keep two concurrent >>>>>> updates, it is easy enough. Just make sure that the update don't end up >>>>>> in >>>>>> the same column. This is easily achieved by appending some unique >>>>>> identifier >>>>>> to the column name for instance. And when reading, do a slice and >>>>>> reconcile >>>>>> whatever you get back with whatever logic make sense. If you do that, >>>>>> congrats, you've roughly emulated what vector clocks would do. Btw, no >>>>>> locking or anything needed. >>>>>> >>>>>> In my experience, for most things the timestamp resolution is enough. >>>>>> If the same user update twice it's profile picture on you web site at the >>>>>> same microsecond, it's usually fine to end up with one of the two >>>>>> pictures. >>>>>> In the rare case where you need something more specific, using the >>>>>> cassandra >>>>>> data model usually solves the problem easily. The reason for not having >>>>>> vector clocks in Cassandra is that so far, we haven't really found much >>>>>> example where it is no the case. >>>>>> >>>>>> -- >>>>>> Sylvain >>>>>> >>>>>> >>>>> >>>> >>> >> >
