Re: Write consistency

2010-04-08 Thread Avinash Lakshman
Retry is the best option. Because the read repair will fix it on a subsequent read and it will actually fix it with a value that was actually deemed a failed write to the client. Avinash On Thu, Apr 8, 2010 at 9:47 AM, David Strauss wrote: > A read repair will fix it immediately after the first

Re: Write consistency

2010-04-08 Thread David Strauss
A read repair will fix it immediately after the first read of the row. On 2010-04-08 16:36, Mark Greene wrote: > So unless you re-try the write, the previous stale write stays on the > other two nodes? Would a read repair fix this eventually? > > On Thu, Apr 8, 2010 at 11:36 AM, Avinash Lakshman

Re: Write consistency

2010-04-08 Thread Benjamin Black
His arguments consistently (hah!) boil down to this: if you misconfigure things for your intended application, you get undesirable behavior. For example, the correct approach to the situation cited is to use quorum reads and writes. W=3/R=1/N=3 might be appropriate for situations in which you wan

Re: Write consistency

2010-04-08 Thread Benjamin Black
Yes. Or you would retry the write. Either way, the system achieves consistency eventually, hence the name. On Thu, Apr 8, 2010 at 9:36 AM, Mark Greene wrote: > So unless you re-try the write, the previous stale write stays on the other > two nodes? Would a read repair fix this eventually? >

Re: Write consistency

2010-04-08 Thread Mark Greene
So unless you re-try the write, the previous stale write stays on the other two nodes? Would a read repair fix this eventually? On Thu, Apr 8, 2010 at 11:36 AM, Avinash Lakshman < avinash.laksh...@gmail.com> wrote: > What your describing is a distributed transaction? Generally strong > consistenc

Re: Write consistency

2010-04-08 Thread Benjamin Black
On Thu, Apr 8, 2010 at 12:55 AM, Paul Prescod wrote: > > ¹ http://jsensarma.com/blog/2009/11/dynamo-part-i-a-followup-and-re-rebuttals/ > Pay no attention to this disingenuous troll. b

Re: Write consistency

2010-04-08 Thread Avinash Lakshman
What your describing is a distributed transaction? Generally strong consistency is always associated with doing transactional writes where you never see the results of a failed write on a subsequent read no matter what happens. Cassandra has no notion of rollback. That is why no combination will gi

Re: Write consistency

2010-04-08 Thread Jeremy Dunck
On Thu, Apr 8, 2010 at 7:16 AM, Gary Dusbabek wrote: > On Thu, Apr 8, 2010 at 02:55, Paul Prescod wrote: >> In this¹ debate, there seemed to be consensus on the following fact: >> >> "In Cassandra, say you use N=3, W=3 & R=1. Let’s say you managed to >> only write to replicas A & B, but not C. In

Re: Write consistency

2010-04-08 Thread Gary Dusbabek
On Thu, Apr 8, 2010 at 02:55, Paul Prescod wrote: > In this¹ debate, there seemed to be consensus on the following fact: > > "In Cassandra, say you use N=3, W=3 & R=1. Let’s say you managed to > only write to replicas A & B, but not C. In this case Cassandra will > return an error to the applicati