[
https://issues.apache.org/jira/browse/KUDU-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15526783#comment-15526783
]
Jean-Daniel Cryans commented on KUDU-352:
-----------------------------------------
The solution I had implemented in the Java client that you were referring to in
your May 14th 2015 comment was completely refactored this summer and we still
retain ordering. So at least on this side we're good.
> Decide on and implement within-batch ordering for client API
> ------------------------------------------------------------
>
> Key: KUDU-352
> URL: https://issues.apache.org/jira/browse/KUDU-352
> Project: Kudu
> Issue Type: New Feature
> Components: client
> Affects Versions: M5
> Reporter: Vladimir Feinberg
>
> Currently, the when the client applies a sequence of WriteOperations to a
> session without flushing (within a single batch), the batcher runs tablet
> location lookup asynchronously (see method Batcher::TabletLookupFinished).
> Thus, it is possible that within the same batch, even with manual flushing,
> the PerTSBuffer is flushed out of order (causing operations to arrive
> out-of-order on the server side).
> A contract needs to be designed (and applied to both C++ and Java APIs)
> regarding the strength of the ordering within the batches.
> Some options:
> 1. No order guaranteed (current). Client must manually flush between batches
> to ensure order.
> 2. Per-row order guarantee - operations are sent to the server where for a
> given key, the sequence of operations is preserved.
> 3. Strict ordering guarantee. Independent of keys, order of batch is matched.
> Things to consider:
> -> Is (2) different from (3)? With HybridTime, the client should only see
> changes atomically on a per-batch level with concurrent reads. Then
> between-row operations do not matter (until multi-row transactions are
> introduced).
> -> A flexible version of the API that could include BarrierWriteOperations
> which would allow the user to control order within batches themselves.
> -> Simplifying things entirely, removing all order (force the client to use a
> transaction or flushes to ensure order).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
