Thank you all for your valuable comments and information.
> Date: Tue, 3 Sep 2013 12:01:59 -0400 > From: email@example.com > To: firstname.lastname@example.org > CC: email@example.com > Subject: Re: row cache > > On 09/01/2013 03:06 PM, Faraaz Sareshwala wrote: > > Yes, that is correct. > > > > The SerializingCacheProvider stores row cache contents off heap. I believe you > > need JNA enabled for this though. Someone please correct me if I am wrong here. > > > > The ConcurrentLinkedHashCacheProvider stores row cache contents on the java heap > > itself. > > > > Naming things is hard. Both caches are in memory and are backed by a > ConcurrentLinkekHashMap. In the case of the SerializingCacheProvider > the *values* are stored in off heap buffers. Both must store a half > dozen or so objects (on heap) per entry > (org.apache.cassandra.cache.RowCacheKey, > com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$WeightedValue, > java.util.concurrent.ConcurrentHashMap$HashEntry, etc). It would > probably be better to call this a "mixed-heap" rather than off-heap > cache. You may find the number of entires you can hold without gc > problems to be surprising low (relative to say memcached, or physical > memory on modern hardware). > > Invalidating a column with SerializingCacheProvider invalidates the > entire row while with ConcurrentLinkedHashCacheProvider it does not. > SerializingCacheProvider does not require JNA. > > Both also use memory estimation of the size (of the values only) to > determine the total number of entries retained. Estimating the size of > the totally on-heap ConcurrentLinkedHashCacheProvider has historically > been dicey since we switched from sizing in entries, and it has been > removed in 2.0.0. > > As said elsewhere in this thread the utility of the row cache varies > from "absolutely essential" to "source of numerous problems" depending > on the specifics of the data model and request distribution. > >