> Since this solution is from the driver, is it correct to assume that
although this could potentially fix the issue within a single (client)
session, it could not fix it for a pool of clients, where client A sent the
first update and client B sent the 2nd one (because driver session doesn't
share
lt;jendaboar...@yahoo.com>
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Sent: Thursday, May 12, 2016 10:32 AM
Subject: client time stamp - force to be continuously increasing?
I'd like to get feedback/opinions on a possible work around for a timestamp +
data consistenc
o:* "user@cassandra.apache.org" <user@cassandra.apache.org>
> *Sent:* Thursday, May 12, 2016 10:32 AM
> *Subject:* client time stamp - force to be continuously increasing?
>
> I'd like to get feedback/opinions on a possible work around for a
> timestamp + data consist
to clarify - the currentRecordTs would be saved on a field on the record being
persisted
From: Jen Smith <jendaboar...@yahoo.com>
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Sent: Thursday, May 12, 2016 10:32 AM
Subject: client time stamp - fo
I'd like to get feedback/opinions on a possible work around for a timestamp +
data consistency edge case issue.
Context for this question:
When using client timestamp (default timestamp), on C* that supports it (v3
protocol), on occasion a record update is lost when executing updates in rapid
