It is my understanding that row cache is on the memory (Not on disk). It could live on heap or native memory depending on the cache provider? Is that right? 

-SC


> Date: Fri, 23 Aug 2013 18:58:07 +0100
> From: bill@dehora.net
> To: user@cassandra.apache.org
> Subject: Re: row cache
>
> I can't emphasise enough testing row caching against your workload for
> sustained periods and comparing results to just leveraging the
> filesystem cache and/or ssds. That said. The default off-heap cache can
> work for structures that don't mutate frequently, and whose rows are not
> very wide such that the in-and-out-of heap serialization overhead is
> minimised (I've seen the off-heap cache slow a system down because of
> serialization costs). The on-heap can do update in place, which is nice
> for more frequently changing structures, and for larger structures
> because it dodges the off-heap's serialization overhead. One problem
> I've experienced with the on-heap cache is the cache working set
> exceeding allocated space, resulting in GC pressure from sustained
> thrash/evictions.
>
> Neither cache seems suitable for wide row + slicing usecases, eg time
> series data or CQL tables whose compound keys create wide rows under the
> hood.
>
> Bill
>
>
> On 2013/08/23 17:30, Robert Coli wrote:
> > On Thu, Aug 22, 2013 at 7:53 PM, Faraaz Sareshwala
> > <fsareshwala@quantcast.com <mailto:fsareshwala@quantcast.com>> wrote:
> >
> > According to the datastax documentation [1], there are two types of
> > row cache providers:
> >
> > ...
> >
> > The off-heap row cache provider does indeed invalidate rows. We're
> > going to look into using the ConcurrentLinkedHashCacheProvider. Time
> > to read some source code! :)
> >
> >
> > Thanks for the follow up... I'm used to thinking of the
> > ConcurrentLinkedHashCacheProvider as "the row cache" and forgot that
> > SerializingCacheProvider might have different invalidation behavior.
> > Invalidating the whole row on write seems highly likely to reduce the
> > overall performance of such a row cache. :)
> >
> > The criteria for use of row cache mentioned up-thread remain relevant.
> > In most cases, you probably don't actually want to use the row cache.
> > Especially if you're using ConcurrentLinkedHashCacheProvider and
> > creating long lived, on heap objects.
> >
> > =Rob
>