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?
--sriram
- "CommitLog" semantics Sriram Srinivasan
-
