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
> Otherwise, it means the version conflict solving s
> 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 eit
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 configu
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
