>> So with the row cache, that first node (the primary replica) is the one that >> has that row cached, yes? > No, it's the closest node as determined by snitch.sortByProximity.
And with the default snitch, rack-unaware placement, random partitioner, and all nodes up, that's the primary replica, right? > any given node X will never know whether another node Y has a row cached or > not. the overhead for communicating that level of detail would be totally > prohibitive. all caching does is speed the read, once a request is received > for data local to a given node. no more, no less. Yes, that's my concern, but the details significantly affect the effective size of the cache (in the afoorementioned case, the details place the effective size at either 6 million or 18 million, a 3x difference). So given CL==ONE reads, only the actually read node (which will be the primary replica given the default placement strategy and snitch) will cache the item, right? The checksum-checking doesn't cause the row to be cached on the non-read nodes? If I read with CL==QUORUM in an RF==3 environment, do both read nodes them cache the item, or only the primary replica?
