Actually I didn't concurrent update the same records, because I first
create it, then search it, then delete it. The version conflict solved
failed, due to delete local time stamp is earlier then create local time
stamp.
2013/3/6 aaron morton aa...@thelastpickle.com
Otherwise, it means the
Otherwise, it means the version conflict solving strong depends on global
sequence id (timestamp) which need provide by client ?
Yes.
If you have an area of your data model that has a high degree of concurrency
C* may not be the right match.
In 1.1 we have atomic updates so clients see
The problem is, what is the sequence number you are talking about is
exactly?
Or let me put it another way: if you do have a sequence number that
provides a total ordering of your operation, then that is exactly what you
should use as your timestamp. What Cassandra calls the timestamp, is
exactly
Hi
The timestamp provided by my client is unix timestamp (with ntp), and as I
said, due to the ntp drift, the local unix timestamp is not accurately
synchronized (compare to my case).
So for short, client can not provide global sequence number to indicate the
event order.
But I wonder, I
