Ah, my mistake, you are correct. Not sure why I had forgotten that. The pycassa docs are slightly wrong there, though. It's technically atomic for the same key across multiple column families. I'll get that fixed.
On Wed, Mar 14, 2012 at 5:22 PM, A J <s5a...@gmail.com> wrote: > > No, batch_mutate() is an atomic operation. When a node locally applies > a batch mutation, either all of the changes are applied or none of them > are.< > The steps in my batch are not confined to a single CF, nor to a single key. > > The documentation says: > datastax: > Column updates are only considered atomic within a given record (row). > > Pycassa.batch: > This interface does not implement atomic operations across column > families. All the limitations of the batch_mutate Thrift API call > applies. Remember, a mutation in Cassandra is always atomic per key > per column family only. > > > On Wed, Mar 14, 2012 at 4:15 PM, Tyler Hobbs <ty...@datastax.com> wrote: > > On Wed, Mar 14, 2012 at 11:50 AM, A J <s5a...@gmail.com> wrote: > >> > >> > >> Are you saying the way 'batch mutate' is coded, the order of writes in > >> the batch does not mean anything ? You can ask the batch to do A,B,C > >> and then D in sequence; but sometimes Cassandra can end up applying > >> just C and A,B (and D) may still not be applied ? > > > > > > No, batch_mutate() is an atomic operation. When a node locally applies a > > batch mutation, either all of the changes are applied or none of them > are. > > > > Aaron was referring to the possibility that one of the replicas received > the > > batch_mutate, but the other replicas did not. > > > > -- > > Tyler Hobbs > > DataStax > > > -- Tyler Hobbs DataStax <http://datastax.com/>
