The problem is, what is the sequence number you are t= alking about is exactly?

Or let me put it another = way: if you do have a sequence number that provides a total ordering of you= r operation, then that is exactly what you should use as your timestamp. Wh= at Cassandra calls the timestamp, is exactly what you call seqID, it's = the number Cassandra uses to decide the order of operation.

Except that in real life, provided you have more than o= ne client talking to Cassandra, then providing a total ordering of operatio= n is hard, and in fact not doable efficiently. So in practice, people use u= nix timestamp (with ntp) which provide a very good while cheap approximatio= n of the real life order of operations.

But again, if you do know how to assign a more precise = "timestamp", Cassandra let you use that: you can provid your own = timestamp (using unix timestamp is just the default). The point being, unix= timestamp is the better approximation we have in practice.

--
Sylvain

On Mon, Mar 4, 2013 at 9:26 AM= , Jason Tang wrote:
Hi

=A0 P= revious I met a consistency problem, you can refer the link below for the w= hole story.

=A0 And after check the code, seems I found some = clue of the problem. Maybe some one can check this.

=A0 For short, I have Cassandra cluster (1.0.3),=A0The consistency level is read/write quorum, replication_factor=A0is 3.= =A0

=A0 Here is event sequence:

seqID =A0 NodeA =A0 NodeB =A0 NodeC
1. =A0 =A0 =A0 =A0 New =A0 =A0= =A0New =A0 =A0 =A0 New
2. =A0 = =A0 =A0 =A0 Update =A0Update =A0 Update
3. =A0 =A0 =A0 =A0 Delete =A0 D= elete =A0 =A0

When try to read from NodeB and NodeC, "Digest mismatch" exception= triggered, so Cassandra try to resolve this version conflict.
But the = result is value "Update".

Here is t= he suspect root cause, the version conflict resolved based on=A0time stamp.=

Node C local time is a bit earlier then node A.

"Update" requests sent from node C with time stam= p 00:00:00.050, "Delete" sent from node A with time stamp 00:00:0= 0.020, which is not same as the event sequence.

So the version conflict resolved incorrectly.<= /font>

=
It is true?

If Yes, then it means, consistency level can secure the con= flict been found, but to solve it correctly, dependence one time synchroniz= ation's accuracy, e.g. NTP ?

=

--e89a8fb207dc430e5204d71abf31--