You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Saurabh Sehgal <sa...@gmail.com> on 2011/03/29 03:21:19 UTC

atomicity in cassandra

I have seen this question pop up once or twice in mailing lists regarding
atomicity when using batch_mutate() operations. I understand that the
operations in batch_mutate() should be idempotent and do not get rolled back
on failures. However, a client crashing (due to machine issues, networking
issue etc) in the middle of such a transaction can leave the data in an
inconsistent state. Is there a way to figure out such inconsistencies ? Will
Cassandra keep a log of failed batch_mutate() operations, or partially
completed operations, that might require manual intervention when the client
comes back up ?

Re: atomicity in cassandra

Posted by Narendra Sharma <na...@gmail.com>.
There is no undo or redo log in Cassandra. From Cassandra perspective if the
operation gets logged in commit log, it is considered committed.

Remember the eventual consistency...



On Mon, Mar 28, 2011 at 6:21 PM, Saurabh Sehgal <sa...@gmail.com>wrote:

> I have seen this question pop up once or twice in mailing lists regarding
> atomicity when using batch_mutate() operations. I understand that the
> operations in batch_mutate() should be idempotent and do not get rolled back
> on failures. However, a client crashing (due to machine issues, networking
> issue etc) in the middle of such a transaction can leave the data in an
> inconsistent state. Is there a way to figure out such inconsistencies ? Will
> Cassandra keep a log of failed batch_mutate() operations, or partially
> completed operations, that might require manual intervention when the client
> comes back up ?
>
>


-- 
Narendra Sharma
Solution Architect
*http://www.persistentsys.com*
*http://narendrasharma.blogspot.com/*