In batch mode, we still block while the commit log is written. See
BatchCommitLogExecutorService.add(). That add() method is what gets
called in Table.apply().
Ah, yes. I did see the .add(), but I missed the .get() wait on the
future.
Thanks much.
--sriram.
first written to the commit log before being
> propagated to the memtable ...
>
> This gives the impression of traditional commitlog semantics found in
> databases and transaction managers, where a sync'd write is a confirmed
> state change.
>
> However, this is NOT th
gives the impression of traditional commitlog semantics found in
databases and transaction managers, where a sync'd write is a
confirmed state change.
However, this is NOT the semantics of the code (db/Table.apply), which
merely queues up a log request to be flushed, then directly pro