cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6178) Consider allowing timestamp at the protocol level ... and deprecating server side timestamps
Date Fri, 13 Jun 2014 21:39:05 GMT


Aleksey Yeschenko commented on CASSANDRA-6178:

[~tupshin] If you are worried about users and usability, then you shouldn't be. With CASSANDRA-6855
in, nothing is going to change for v3-protocol users - the driver will generate the timestamp
automatically and transparently behind the scenes, unless you provide one explicitly. And,
as mentioned in #6855 comments, it's the necessary precondition for idempotent retries in
the driver.

> Consider allowing timestamp at the protocol level ... and deprecating server side timestamps
> --------------------------------------------------------------------------------------------
>                 Key: CASSANDRA-6178
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
> Generating timestamps server side by default for CQL has been done for convenience, so
that end-user don't have to provide one with every query.  However, doing it server side has
the downside that updates made sequentially by one single client (thread) are no guaranteed
to have sequentially increasing timestamps. Unless a client thread is always pinned to one
specific server connection that is, but no good client driver out (that is, including thrit
driver) there does that because that's contradictory to abstracting fault tolerance to the
driver user (and goes again most sane load balancing strategy).
> Very concretely, this means that if you write a very trivial test program that sequentially
insert a value and then erase it (or overwrite it), then, if you let CQL pick timestamp server
side, the deletion might not erase the just inserted value (because the delete might reach
a different coordinator than the insert and thus get a lower timestamp). From the user point
of view, this is a very confusing behavior, and understandably so: if timestamps are optional,
you'd hope that they are least respect the sequentiality of operation from a single client
> Of course we do support client-side assigned timestamps so it's not like the test above
is not fixable. And you could argue that's it's not a bug per-se.  Still, it's a very confusing
"default" behavior for something very simple, which suggest it's not the best default.
> You could also argue that inserting a value and deleting/overwriting right away (in the
same thread) is not something real program often do. And indeed, it's likely that in practice
server-side timestamps work fine for most real application. Still, it's too easy to get counter-intuitive
behavior with server-side timestamps and I think we should consider moving away from them.
> So what I'd suggest is that we push back the job of providing timestamp client side.
But to make it easy for the driver to generate it (rather than the end user), we should allow
providing said timestamp at the protocol level.
> As a side note, letting the client provide the timestamp would also have the advantage
of making it easy for the driver to retry failed operations with their initial timestamp,
so that retries are truly idempotent.

This message was sent by Atlassian JIRA

View raw message