Thanks, Victor. Even in our application, it will be an advantage if the data can be immediately read and reads don't miss it for even the smallest amount of time after write queries have been executed at the app level.
I am in the middle of migrating an app to Cassandra and observing some small app level issues, and wanted to rule out this one as a possibility. Cheers, Roshan On Tue, Jan 25, 2011 at 9:23 AM, Victor Kabdebon <victor.kabde...@gmail.com>wrote: > Hello, > > Roshan basically what happens to your one node server is : > Your insert operation is recorded in the commitlog, then to the MemTable of > the ColumnFamily. Flushing to Memtable is triggered after and your flush > those memtables. > The Memtable holds the data in your node memory and so your insert will be > in either one of those structures. It can be immediately read. And if I can > add this is one of the advantage of Cassandra : the data is inserted and > "ready to use" immediately after it has been received by the node. > > Best Regards, > Victor Kabdebon > http://www.voxnucleus.fr > > 2011/1/24 Roshan Dawrani <roshandawr...@gmail.com> > > Hi, >> >> I have a basic question - maybe silly too. >> >> Say, I have a 1-node Cassandra setup (no replication, eventual >> consistency, etc) and I do an insert into a column family and then very >> close in time to the insert, I do a read on it for the same data. >> >> Is there a possibility that my read operation may miss the data that just >> got inserted? >> >> Since there are no DB transactions in Cassandra, are writes immediately >> seen to readers - even partially as they get written? >> >> Or can there be a delay sometimes due to flusing-to-SSTables, etc? >> >> Or, the writes are first in-memory and immediately visible to readers and >> flusing, etc is independent of all this and happens in background? >> >> Thanks. >> >> -- >> Roshan >> Blog: http://roshandawrani.wordpress.com/ >> Twitter: @roshandawrani <http://twitter.com/roshandawrani> >> Skype: roshandawrani >> >
