Here's my understanding of things ... (this applies only for the regular heap implementation of row cache)
> Why Cassandra does not cache a row that was requested few times? What does the cache capacity read. Is it > 0? > What the ReadCount attribute in ColumnFamilies indicates and why it remains > zero. Hm I had that too one time (read count wont go up while there were reads). But I didn't have the time to debug. > How can I know from where Cassandra read a row (from MEMTable,RowCache or > SSTable)? It will always read from row cache or memtable(s) and sstable(s) jmx should tell you (hits go up) > does the following correct? In read operation Cassandra looks for the row in > the MEMTable - if not found it looks in the row-cache - if not found it looks > in SSTable (after looking in the key-cache to optimize the access to the > SSTable)? No. If row cache capacity is > 0 then a read will check if the row is in cache if not it read the entire row and cache it. Then / or if row was in cache already it will read from there and apply the respective filter to the cached CF. Writes update memtable and row cache when the row is cached. I must admit that I still dont quite understand why there's no race here. I haven't found any cache lock. So someone else should explain why a concurrent read / write cannot produce a lost update in the cached row. If capacity is 0 then it will read from the current memtable, the memtable(s) that are being flushed and all sstables that may contain the row (filtered by bloom filter) Hope that's correct and helps. Cheers, Daniel
