cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peddi, Praveen" <>
Subject Re: Overriding timestamp with light weight transactions
Date Tue, 17 Nov 2015 01:32:53 GMT
Adding sleep was our last resort but I was hoping to find a way that doesn't affect our API
latencies. Thanks for the suggestion though.


On Nov 16, 2015, at 6:29 PM, Laing, Michael <<>>

So you are reading the row before writing as you say you have the timestamp.

If you really need CAS for the write and the timestamp you read is in the future (by local
reckoning), why not delay that write until the future arrives and forget about explicitly
setting the timestamp?

Backtracking on timestamps is definitely a consistency risk anyway, as I understand it, since
the 'latest' one wins and could easily be lurking in a hint somewhere etc.

On Mon, Nov 16, 2015 at 4:27 PM, Peddi, Praveen <<>>
Thanks for your response. Our custom supplied timestamp is only provided if current timestamp
on the row is in future. We just add few millis to current timestamp value and override the
timestamp. That will ensure the updates are read in the correct order. We don’t completely
manage the timestamp field by ourselves, but only when row’s current timestamp is in future.
This approach seems to be working fine for us (running for last 6 weeks).

As far as multiple updates with in few ms, that is the nature of our system. Its only a very
small percent of our requests that can come in rapid fire but when it happens, we need to
handle it. With out ntp drift issues (or minimal drift), there are absolutely no issues. Only
when the drift is significant (Europe’s case), it becomes a problem and the above approach
has solved it nicely.


From: Jon Haddad <<>>
on behalf of Jon Haddad <<>>
Reply-To: "<>" <<>>
Date: Monday, November 16, 2015 at 4:05 PM
To: "<>" <<>>
Subject: Re: Overriding timestamp with light weight transactions

LWT uses the coordinator’s machine’s timestamp to generate a timeuuid, which is used as
the timestamp of the paxos ballot.  You cannot supply a paxos ballot that’s behind the current
time because it’s invalid.

You’re issuing multiple updates within a few ms in a distributed system, it sounds like
you’re trying to ignore the real world problem of clock variance.  If you understand that
you’ve got clocks that are going to be more than 10ms off, and you’re issuing queries
within a few ms of each other, why do you think that your custom supplied timestamps are going
to be correct?

On Nov 16, 2015, at 1:01 PM, Peddi, Praveen <<>>

We have some rapid fire updates (multiple updates with in few millis). I wish we had control
over ntp drifts but AWS doesn’t guarantee “0 drift”. In North America, its minimal (<5
to 10 ms) but Europe has longer drifts. We override the timestamp only if we see current timestamp
on the row is in future. Why do you think overriding timestamp is a work around? It seems
like a valid reason to override timestamps.


From: Jon Haddad <<>>
on behalf of Jon Haddad <<>>
Reply-To: "<>" <<>>
Date: Monday, November 16, 2015 at 3:42 PM
To: "<>" <<>>
Subject: Re: Overriding timestamp with light weight transactions

Perhaps you should fix your clock drift issues instead of trying to use a workaround?

On Nov 16, 2015, at 11:39 AM, Peddi, Praveen <<>>

We are using Cassandra 2.0.9 and we currently have “using timestamp” clause in all our
update queries. We did this to fix occasional issues with ntp drift on AWS. We recently introduced
conditional update in couple of our API and we realized that I can’t have “using timestamp”
and “if column1=?” in the same query.

com.datastax.driver.core.exceptions.InvalidQueryException: Cannot provide custom timestamp
for conditional update

How do I achieve this if I want to override timestamp in a query with conditional update?
Also, does anyone know the reason behind not supporting “using timestamp” for conditional
update? I am trying to understand the problems this would cause.


View raw message