[jira] [Resolved] (KUDU-352) Decide on and implement within-batch ordering for client API

["Jean-Daniel Cryans (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KUDU-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Daniel Cryans resolved KUDU-352.
-------------------------------------
       Resolution: Done
    Fix Version/s: n/a

Calling this done. We currently guarantee the order within a batch for MANUAL_FLUSH mode in both clients. Order isn't guaranteed with AUTO_FLUSH_BACKGROUND in the C++ client (see KUDU-1767) but it is in the Java client (it only flushes one buffer at a time instead of 2 like in C++).

> 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
>             Fix For: n/a
>
>
> 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.4.14#64029)