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.
