Hi Jon,

Thanks a lot for your response. I am well aware that the LWW != LWT but I
was talking more in terms of LWW with respective to LWT's which I believe
you answered. so thanks much!

kant

On Thu, Feb 9, 2017 at 6:01 PM, Jon Haddad <jonathan.had...@gmail.com>
wrote:

> LWT != Last Write Wins.  They are totally different.
>
> LWTs give you (assuming you also read at SERIAL) “atomic consistency”,
> meaning you are able to perform operations atomically and in isolation.
> That’s the safety blanket everyone wants but is extremely expensive,
> especially in Cassandra.  The lightweight part, btw, may be a little
> optimistic, especially if a key is under contention.  With regard to the
> “last write” part you’re asking about - w/ LWT Cassandra provides the
> timestamp and manages it as part of the ballot, and it always is
> increasing.  See 
> org.apache.cassandra.service.ClientState#getTimestampForPaxos.
> From the code:
>
>  * Returns a timestamp suitable for paxos given the timestamp of the last
> known commit (or in progress update).
>  * Paxos ensures that the timestamp it uses for commits respects the
> serial order of those commits. It does so
>  * by having each replica reject any proposal whose timestamp is not
> strictly greater than the last proposal it
>  * accepted. So in practice, which timestamp we use for a given proposal
> doesn't affect correctness but it does
>  * affect the chance of making progress (if we pick a timestamp lower than
> what has been proposed before, our
>  * new proposal will just get rejected).
>
> Effectively paxos removes the ability to use custom timestamps and
> addresses clock variance by rejecting ballots with timestamps less than
> what was last seen.  You can learn more by reading through the other
> comments and code in that file.
>
> Last write wins is a free for all that guarantees you *nothing* except the
> timestamp is used as a tiebreaker.  Here we acknowledge things like the
> speed of light as being a real problem that isn’t going away anytime soon.
> This problem is sometimes addressed with event sourcing rather than
> mutating in place.
>
> Hope this helps.
>
> Jon
>
>
> On Feb 9, 2017, at 5:21 PM, Kant Kodali <k...@peernova.com> wrote:
>
> @Justin I read this article http://www.datastax.com/dev/
> blog/lightweight-transactions-in-cassandra-2-0. And it clearly says
> Linearizable consistency can be achieved with LWT's.  so should I assume
> the Linearizability in the context of the above article is possible with
> LWT's and synchronization of clocks through ntpd ? because LWT's also
> follow Last Write Wins. isn't it? Also another question does most of the
> production clusters do setup ntpd? If so what is the time it takes to sync?
> any idea
>
> @Micheal Schuler Are you referring to  something like true time as in
> https://static.googleusercontent.com/media/research.google.com/en//
> archive/spanner-osdi2012.pdf?  Actually I never heard of setting up GPS
> modules and how that can be helpful. Let me research on that but good point.
>
> On Thu, Feb 9, 2017 at 5:09 PM, Michael Shuler <mich...@pbandjelly.org>
> wrote:
>
>> If you require the best precision you can get, setting up a pair of
>> stratum 1 ntpd masters in each data center location with a GPS modules
>> is not terribly complex. Low latency and jitter on servers you manage.
>> 140ms is a long way away network-wise, and I would suggest that was a
>> poor choice of upstream (probably stratum 2 or 3) source.
>>
>> As Jonathan mentioned, there's no guarantee from Cassandra, but if you
>> need as close as you can get, you'll probably need to do it yourself.
>>
>> (I run several stratum 2 ntpd servers for pool.ntp.org)
>>
>> --
>> Kind regards,
>> Michael
>>
>> On 02/09/2017 06:47 PM, Kant Kodali wrote:
>> > Hi Justin,
>> >
>> > There are bunch of issues w.r.t to synchronization of clocks when we
>> > used ntpd. Also the time it took to sync the clocks was approx 140ms
>> > (don't quote me on it though because it is reported by our devops :)
>> >
>> > we have multiple clients (for example bunch of micro services are
>> > reading from Cassandra) I am not sure how one can achieve
>> > Linearizability by setting timestamps on the clients ? since there is no
>> > total ordering across multiple clients.
>> >
>> > Thanks!
>> >
>> >
>> > On Thu, Feb 9, 2017 at 4:16 PM, Justin Cameron <jus...@instaclustr.com
>> > <mailto:jus...@instaclustr.com>> wrote:
>> >
>> >     Hi Kant,
>> >
>> >     Clock synchronization is important - you should ensure that ntpd is
>> >     properly configured on all nodes. If your particular use case is
>> >     especially sensitive to out-of-order mutations it is possible to set
>> >     timestamps on the client side using the
>> >     drivers. https://docs.datastax.com/en/d
>> eveloper/java-driver/3.1/manual/query_timestamps/
>> >     <https://docs.datastax.com/en/developer/java-driver/3.1/m
>> anual/query_timestamps/>
>> >
>> >     We use our own NTP cluster to reduce clock drift as much as
>> >     possible, but public NTP servers are good enough for most
>> >     uses. https://www.instaclustr.com/blog/2015/11/05/apache-cassandra
>> -synchronization/
>> >     <https://www.instaclustr.com/blog/2015/11/05/apache-cassand
>> ra-synchronization/>
>> >
>> >     Cheers,
>> >     Justin
>> >
>> >     On Thu, 9 Feb 2017 at 16:09 Kant Kodali <k...@peernova.com
>> >     <mailto:k...@peernova.com>> wrote:
>> >
>> >         How does Cassandra achieve Linearizability with “Last write
>> >         wins” (conflict resolution methods based on time-of-day clocks)
>> ?
>> >
>> >         Relying on synchronized clocks are almost certainly
>> >         non-linearizable, because clock timestamps cannot be guaranteed
>> >         to be consistent with actual event ordering due to clock skew.
>> >         isn't it?
>> >
>> >         Thanks!
>> >
>> >     --
>> >
>> >     Justin Cameron
>> >
>> >     Senior Software Engineer | Instaclustr
>> >
>> >
>> >
>> >
>> >     This email has been sent on behalf of Instaclustr Pty Ltd
>> >     (Australia) and Instaclustr Inc (USA).
>> >
>> >     This email and any attachments may contain confidential and legally
>> >     privileged information.  If you are not the intended recipient, do
>> >     not copy or disclose its content, but please reply to this email
>> >     immediately and highlight the error to the sender and then
>> >     immediately delete the message.
>> >
>> >
>>
>>
>
>

Reply via email to