[
https://issues.apache.org/jira/browse/CASSANDRA-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791846#comment-13791846
]
Jonathan Ellis commented on CASSANDRA-6178:
-------------------------------------------
I dunno; I feel like this is over-reacting to client connection pooling. "I
want my operations to be sequential wrt to the order the client issued them"
sounds like a lot like "I want read-my-writes consistency" which is also only
sane if restricted to a single session (connection).
> Consider allowing timestamp at the protocol level ... and deprecating server
> side timestamps
> --------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-6178
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6178
> 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 thread.
> 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
(v6.1#6144)
