> 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 memory/data between clients)? Is this correct? if so, I think this
doesn't provide the full HA client solution.

That is correct.

> but I think it does help to confirm that a 'reasonable' approach to
solving the overall problem is software enforcement of a 'rigorously
increasing timestamp' with the understood impact of drifting our timestamps
out into the future (when conflict is identified).  it also sounds like
from that jira ticket, the continually updating increment can be
miliseconds, not seconds.

The driver's timestamp generators all have microsecond granularity
actually. So timestamps get incremented microsecond by microsecond when the
system clock goes astray.


On Sat, May 14, 2016 at 6:18 PM Eric Evans <john.eric.ev...@gmail.com>
wrote:

> On Thu, May 12, 2016 at 10:32 AM, Jen Smith <jendaboar...@yahoo.com>
> wrote:
> >
> > My question is if this can be addressed via software by (using? abusing?)
> > the client provided timestamp field and forcing it to be continuously
> > increasing, and what unexpected issues may arise from doing so?
>
> I'm not sure if you're looking for an answer for your own particular
> use-case(s), or something more general, but I thought I'd point out
> that client-provided timestamps are as much a feature in other
> contexts as they are a bug in this one, precisely because they *can*
> be out of order; They are meant to represent a causal ordering.
>
> In other words, if you somehow unconditionally enforced monotonicity
> on the server side[*] you'd break a whole other set of use-cases.
>
>
> [*]: But, how would you even manage such a thing without coordination,
> in a distributed environment?
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>
-- 
Alexandre Dutra
Driver & Tools Engineer @ DataStax

Reply via email to