Ok, thanks.

On Fri, May 6, 2011 at 8:32 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
Column objects are treated as immutable so it's quite likely you'll
get back the same Columns (and buffers) if your query hits a local
memtable.  This was possible in 0.7.0 as well.
It's funny as this was a unit test that just put a set of columns and then read them twice, back to back. It never failed in 0.7.0, but failed first and every run in 0.7.5.

(This only applies to the StorageProxy interface, if you're going over
Thrift it will do a copy over the network.)

On Thu, May 5, 2011 at 12:34 PM, Paul Loy <keteracel@gmail.com> wrote:
> Hi all,
> so I just updated Cassandra from 0.7.0 to 0.7.5. I embed Cassandra in my app
> and use StorageProxy for querying.
> In one of my unit tests I write a column to Cassandra and then read it out
> again twice in quick succession. The second time I now get the same
> ByteBuffer (i.e. same id - same 'physical' HeapByteBuffer) as the first
> call. But as I have consumed this, the position == capacity.
> I have fixed this in my code by simply using ByteBuffer#duplicate, however
> I'm concerned that caching may have changed between versions and want to
> know what the implications of that change may be.
> So my questions are:
> 1) is the Row Cache now enabled by default?
> 2) or is there now some other form of caching that is causing this to happen
> that I should be aware of?
> We're pretty close to deploying into production when we came across a
> critical bug in 0.7.0 (infinite loop in HashMap) which means we have to
> upgrade but I'm concerned that the changes mean our load/stress tests will
> not be valid so just need some info to put my mind at ease!
> Many thanks,
> Paul.
> --
> ---------------------------------------------
> Paul Loy
> paul@keteracel.com
> http://uk.linkedin.com/in/paulloy

Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support

Paul Loy