[
https://issues.apache.org/jira/browse/KUDU-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15530674#comment-15530674
]
Alexey Serbin commented on KUDU-352:
------------------------------------
As [~jdcryans] mentioned, Java client provides ordering guarantee, as I can see.
For the C++ client:
* As for the within-one-batch ordering, the issue has been fixed a long time
ago (as mentioned earlier) and now we have ordering guarantee there.
* As for the across-batches ordering:
** if the limit on number of batchers is to 1, then we have strict ordering
** if the limit on number of batchers is 2 (default) or more, then operations
can be re-ordered across different batches.
> 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)
