Roshan, when a client invoke a write, the write goes first to commit log and later to memtable. After that it returns to the client.
After it reaches the memtable, that data is ready to be read. The reads consolidates de data from the memtables and sstables unless there is a hit in the row cache. does it help? On Mon, Jan 24, 2011 at 8:57 PM, Roshan Dawrani <roshandawr...@gmail.com>wrote: > Thanks for your inputs, Victor. > > In my app, it's a bit event driven. > > We do writes and fire events and listeners then read - so we can't predict > how soon the reads will come. Sometimes they came too fast, which is better > for our app, if we can have a Cassandra DB level understanding that they > won't miss the writes, if they come too fast :-) > > Or, if there is anything we should do to make sure that reads happen in an > assured manner. > > > On Tue, Jan 25, 2011 at 10:22 AM, Victor Kabdebon < > victor.kabde...@gmail.com> wrote: > >> Again don't take it as a 100% sure answer because it is not an area that I >> have really explored. >> >> So yes I think that reads are made from Memtables. >> Theoretically yes, however it is very unlikely : your get must be build >> and send before the commitlog updates the Memtable (which is like inserting >> in a Memtable, a matter of microseconds). >> Possible configuration : Just wait a second or so to do your "get" query >> (I imagine that it works after one second because you don't report this >> problem)... Other than that no not really. I have not done any application >> with those time constraints. >> >> Best regards, >> Victor Kabdebon >> >> 2011/1/24 Roshan Dawrani <roshandawr...@gmail.com> >> >>> On Tue, Jan 25, 2011 at 9:57 AM, Victor Kabdebon < >>> victor.kabde...@gmail.com> wrote: >>> >>> As far as I remember, please correct me if I am wrong, on a one node >>>> cluster : >>>> First Commitlog is updated then almost immediatly after order is send to >>>> the memtable to add this new insert. You might have a very short delay >>>> between the two. I don't know your configuration but especially if you >>>> insert from a distant server to a node you should look at their sync.. >>>> Otherwise if it doesn't appear I can offer no explanation for this >>>> behavior... >>>> >>> >>> As of now, I am on an app server with an embedded cassandra server, so no >>> possibility of clocks out-of-sync. >>> >>> So, I understand from you that client call returns after updating the >>> commit log and updates to memtables are async after that - with >>> how-much-ever short a delay tried by Cassandra? >>> >>> And the reads are always off memtables? >>> >>> So, theoretically, there is a possibility of a read missing a write >>> because it has not come to memtables from the commit log yet? >>> >>> Is there anything that I can tell about my configuration that would help? >>> >> >> >
