replicas).
During reads, the latest write wins.
What if there is a clock skew ? It could lead to a stale write
over-riding the actual latest write, just because the clock of that
node is ahead of the other node. Right ?
> that node (correct me if that is not the case and the system-time of
>> the co-ordinator is what gets applied to all the replicas).
>> During reads, the latest write wins.
>>
>> What if there is a clock skew ? It could lead to a stale write
>> over-riding the ac
> During reads, the latest write wins.
>
> What if there is a clock skew ? It could lead to a stale write
> over-riding the actual latest write, just because the clock of that
> node is ahead of the other node. Right ?
>
On Tue, 2011-06-28 at 11:54 +1200, aaron morton wrote:
> Without exception the timestamp is set by the client, not the server.
> The one exception to the without exception rule is CounterColumnType
> operations.
And CQL...
--
Eric Evans
eev...@rackspace.com
e if that is not the case and the system-time of
> > the co-ordinator is what gets applied to all the replicas).
> > During reads, the latest write wins.
> >
> > What if there is a clock skew ? It could lead to a stale write
> > over-riding the actual latest write, just because the clock of that
> > node is ahead of the other node. Right ?
>
>
ordinator is what gets applied to all the replicas).
> During reads, the latest write wins.
>
> What if there is a clock skew ? It could lead to a stale write
> over-riding the actual latest write, just because the clock of that
> node is ahead of the other node. Right ?
During writes, the timestamp field in the column is the system-time of
that node (correct me if that is not the case and the system-time of
the co-ordinator is what gets applied to all the replicas).
During reads, the latest write wins.
What if there is a clock skew ? It could lead to a stale
