Hi Daniel, For a general theoretical understanding, try reading some of the papers on eventual consistency by Werner Vogels.
Reading the SOSP'07, Dynamo paper would also help with some of the theoretical foundations and academic references. To get even further into it, try reading Replication Techniques in Distributed Systems by Abdelsalam Helal, Abdelsalam Heddaya and Bharat Bhargava ( http://www.amazon.com/Replication-Techniques-Distributed-Advances-Database/dp/0792398009/ref=sr_1_12?ie=UTF8&s=books&qid=1271891223&sr=8-12) Regards, m. 2010/4/21 Даниел Симеонов <dsimeo...@gmail.com> > Hi Paul, > about the last answer I still need some more clarifications, as I > understand it if QUORUM is used, then reads doesn't get old values either? > Or am I wrong? > Thank you very much! > Best regards, Daniel. > > 2010/4/21 Paul Prescod <pres...@gmail.com> > > I'm not an expert, so take what I say with a grain of salt. >> >> 2010/4/21 Даниел Симеонов <dsimeo...@gmail.com>: >> > Hello, >> > I am pretty new to Cassandra and I have some questions, they may seem >> > trivial, but still I am pretty new to the subject. First is about the >> lack >> > of a compareAndSet() operation, as I understood it is not supported >> > currently in Cassandra, do you know of use cases which really require >> such >> > operations and how these use cases currently workaround this . >> >> I think your question is paradoxical. If the use case really requires >> the operation then there is no workaround by definition. The existence >> of the workaround implies that the use case really did not require the >> operation. >> >> Anyhow, vector clocks are probably relevant to this question and your next >> one. >> >> > Second topic I'd like to discuss a little bit more is about the read >> repair, >> > as I understand is that it is being done by the timestamps supplied by >> the >> > client application servers. Since computer clocks (which requires >> > synchronization algorithms working regularly) diverge there should be a >> time >> > frame during which the order of the client request written to the >> database >> > is not guaranteed, do you have real world experiences with this? Is this >> > similar to the casual consistency ( >> > http://en.wikipedia.org/wiki/Causal_consistency ) .What happens if two >> > application servers try to update the same data and supply one and the >> same >> > timestamp (it could happen although rarely), what if they try to update >> > several columns in batch operation this way, is there a chance that the >> > column value could be intermixed between the two update requests? >> >> All of this is changing with vector clocks in Cassandra 0.7. >> >> https://issues.apache.org/jira/browse/CASSANDRA-580 >> >> > I have one last question about the consistency level ALL, do you know of >> > real use cases where it is required (instead of QUORUM) and why (both >> read >> > and write)? >> >> It would be required when your business rules do not allow any client >> to read the old value. For example if it would be illegal to provide >> an obsolete stock value. >> >> > Thank you very much for your help to better understand 'Cassandra'! >> > Best regards, Daniel. >> > >> > >
