On Mon, Jun 28, 2010 at 04:44, Sriram Srinivasan <sri...@malhar.net> wrote: > Hiya. > > The architecture internals document and various presentations (such as > http://www.slideshare.net/jhammerb/data-presentations-cassandra-sigmod) say > something like the following: > > ... a row mutation is 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 the semantics of the code (db/Table.apply), which > merely queues up a log request to be flushed, then directly proceeds to > update the memtable. Which means it is possible for a client to receive a > confirmation (even in a quorum case) before the data has been written to > disk. > > Am I wrong?
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(). Gary. > > --sriram > > >
