Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of narendra.sharma@gmail.com
 designates 209.85.161.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=ikXhDRMTzXRl0L52BFH4ViIK3HXoqlc8yUXJ1CnoxPu3nOSWEK6qWxqBkwmZLhVKZz
         oySsN9vbGNOARfZw8H15UiuFz4f9wJcLLq/IQWAVzhuZ74TDWbVjIDxPIQFuqB++dCsl
         MAborxOjDh/0bZ25y2td8yN0Pdx3gGSasDgTQ=
MIME-Version: 1.0
In-Reply-To: <AANLkTikFKYT6jy9vk2kWrwfH=svE68wvedimwATCrNm_@mail.gmail.com>
References: <AANLkTikFKYT6jy9vk2kWrwfH=svE68wvedimwATCrNm_@mail.gmail.com>
Date: Mon, 28 Mar 2011 20:22:52 -0700
Message-ID: <AANLkTikQ-bt-ytEvJqfHLGBNwEubC+NrqCsjuO7EqfWm@mail.gmail.com>
Subject: Re: atomicity in cassandra
From: Narendra Sharma <narendra.sharma@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=001636af017e50971d049f9693fa

--001636af017e50971d049f9693fa
Content-Type: text/plain; charset=ISO-8859-1

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 <saurabh.r.s@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/*

--001636af017e50971d049f9693fa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There is no undo or redo log in Cassandra. From Cassandra perspective if th=
e operation gets logged in commit log, it is considered committed.<div><br>=
</div><div>Remember the eventual consistency...</div><div><br></div><div>
<br><br><div class=3D"gmail_quote">On Mon, Mar 28, 2011 at 6:21 PM, Saurabh=
 Sehgal <span dir=3D"ltr">&lt;<a href=3D"mailto:saurabh.r.s@gmail.com">saur=
abh.r.s@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<span style=3D"border-collapse:collapse;font-family:arial, sans-serif;font-=
size:13px">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 rolle=
d back on failures. However, a client crashing (due to machine issues, netw=
orking 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 partiall=
y completed operations, that might require manual intervention when the cli=
ent comes back up ?</span><div>

<div><font face=3D"arial, sans-serif"><span style=3D"border-collapse:collap=
se"><br></span></font>
</div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><font color=3D"#999999"=
>Narendra Sharma</font><div><font color=3D"#999999">Solution Architect</fon=
t><br><div><i><a href=3D"http://www.persistentsys.com" target=3D"_blank">ht=
tp://www.persistentsys.com</a></i></div>
<div><i><a href=3D"http://narendrasharma.blogspot.com/" target=3D"_blank">h=
ttp://narendrasharma.blogspot.com/</a></i></div><div><br></div></div><br>
</div>

--001636af017e50971d049f9693fa--