[ 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)