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 <pe...@amazon.com> wrote: > Jon, > 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. > > Praveen > > From: Jon Haddad <jonathan.had...@gmail.com> on behalf of Jon Haddad < > j...@jonhaddad.com> > Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> > Date: Monday, November 16, 2015 at 4:05 PM > To: "user@cassandra.apache.org" <user@cassandra.apache.org> > 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 <pe...@amazon.com> wrote: > > 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. > > Thanks > Praveen > > > From: Jon Haddad <jonathan.had...@gmail.com> on behalf of Jon Haddad < > j...@jonhaddad.com> > Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> > Date: Monday, November 16, 2015 at 3:42 PM > To: "user@cassandra.apache.org" <user@cassandra.apache.org> > 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 <pe...@amazon.com> wrote: > > Hi, > 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. > > Thanks > Praveen > > > >
