incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Dusbabek <gdusba...@gmail.com>
Subject Re: "CommitLog" semantics
Date Mon, 28 Jun 2010 12:30:30 GMT
On Mon, Jun 28, 2010 at 04:44, Sriram Srinivasan <sriram@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
>
>
>

Mime
View raw message