Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
MIME-Version: 1.0
In-Reply-To: <581603265.1744021.1436389673407.JavaMail.yahoo@mail.yahoo.com>
References: <581603265.1744021.1436389673407.JavaMail.yahoo@mail.yahoo.com>
Date: Wed, 8 Jul 2015 15:06:46 -0700
Message-ID: 
 <CAEDUwd1XGt0DNjyxX1CWwEidCUofvSoJZcFY_=CTY+vfV6cC=Q@mail.gmail.com>
Subject: Re: Read Repair
From: Robert Coli <rcoli@eventbrite.com>
To: "user@cassandra.apache.org" <user@cassandra.apache.org>,
 Saladi Naidu <naidusp2002@yahoo.com>
Content-Type: multipart/alternative; boundary=001a11c3f5bed98828051a645a1a

--001a11c3f5bed98828051a645a1a
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 8, 2015 at 2:07 PM, Saladi Naidu <naidusp2002@yahoo.com> wrote:

> Suppose I have a row of existing data with set of values for attributes I
> call this State1, and issue an update to some columns with Quorum
> consistency.  If the write is succeeded in one node, Node1 and and failed
> on remaining nodes. As there is no Rollback, Node1 row attributes will
> remain new state, State2 and rest of the nodes row will have old state,
> State1. If I do a Read and Cassandra detects state difference, it will
> issue a Read repair which will result in new state, State2 being propagated
> to other nodes. But from a application point of view the update never
> happened because it received an exception.
>

Yes, that's correct. This is the property I call "coalescing to an
un-acknowledged-write," which is extremely unusual to find in
non-distributed, non-log-structured databases.

How to handle this kind of a situation?
>

Design your application in such a way that operations are idempotent and
therefore retryable on failure.

=Rob

--001a11c3f5bed98828051a645a1a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jul 8, 2015 at 2:07 PM, Saladi Naidu <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:naidusp2002@yahoo.com" target=3D"_blank">naidusp2002@yahoo.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"><div><div style=3D"color:=
#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helveti=
ca,Arial,Lucida Grande,sans-serif;font-size:14px"><div dir=3D"ltr"><span>Su=
ppose I have a row of existing data with set of values for attributes I cal=
l this State1, and issue an update to some columns with Quorum consistency.=
=C2=A0 If the write is succeeded in one node, Node1 and and failed on=C2=A0=
remaining=C2=A0nodes. As there is no Rollback, Node1 row attributes will re=
main new state, State2 and rest of the nodes row will have old state, State=
1. If I do a Read and Cassandra detects state difference, it will issue a R=
ead repair which will result in new state, State2 being propagated to other=
 nodes. But from a application point of view the update never happened beca=
use it received an exception. </span></div></div></div></blockquote><div><b=
r></div><div>Yes, that&#39;s correct. This is the property I call &quot;coa=
lescing to an un-acknowledged-write,&quot; which is extremely unusual to fi=
nd in non-distributed, non-log-structured databases.</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div><div style=3D"color:#000;background-color=
:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grand=
e,sans-serif;font-size:14px"><div dir=3D"ltr"><span>How to handle this kind=
 of a situation?</span></div></div></div></blockquote><div><br></div><div>D=
esign your application in such a way that operations are idempotent and the=
refore retryable on failure.</div><div><br></div><div>=3DRob=C2=A0</div></d=
iv></div></div>

--001a11c3f5bed98828051a645a1a--