Uploaded image for project: 'Kudu'
  1. Kudu
  2. KUDU-352

Decide on and implement within-batch ordering for client API



    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: M5
    • Fix Version/s: n/a
    • Component/s: client
    • Labels:


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


          Issue Links



              • Assignee:
                vladimir.feinberg Vladimir Feinberg
              • Votes:
                0 Vote for this issue
                4 Start watching this issue


                • Created: