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
|