You are correct. In this case, Cassandra would journal two writes to the same logical row, but they would be 2 independent writes. Writes do not depend on reads, so they are self-contained. If either column exists already, it will be overwritten.
These journaled actions would then be applied to the memtables, and optionally to the on-disk structures depending on the configuration. (Asynchronous accumulation and flushing provides the best performance, but "write through" persistence is an option in the config) The memtables may have to be read and written, but they only keep a logical instance of each row, from what I know. Maybe a dev can confirm this. On Tue, Jul 20, 2010 at 2:58 PM, Alex Yiu <bigcontentf...@gmail.com> wrote: > > > Hi, > I have more questions on Cassandra ACID properties. > Say, I have a row that has 3 columns already: colA, colB and colC > And, if two *concurrent* clients perform a different insert(...) into the > same row, > one insert is for colD and the other insert is for colE. > Then, Cassandra would guarantee both columns will be added to the same row. > Is that correct? > That is, insert(...) of a column does NOT involving reading and rewriting > other existing columns of the same row? > That is, we do not face the following situation: > client X: read colA, colB and colC; then write: colA, colB, colC and colD > client Y: read colA, colB and colC; then write: colA, colB, colC and colE > > BTW, it seems to me that insert() API as described in the wiki page: > http://wiki.apache.org/cassandra/API > should handle updating an existing column as well by the replacing the > existing column value. > If that is the case, I guess we should change the wording from "insert" to > "insert or update" in the wiki doc > And, ideally, insert(...) API operation name would be adapted > to update_or_insert(...) > > Looking forward to replies that may confirm my understanding. > Thanks! > > Regards, > Alex Yiu > >
