Authoritative failed write: Using paxos to "cancel" failed quorum writes

[Wayne Schroeder <ws...@pinsightmedia.com>]

As I understand it, even though a quorum write fails, the data is still (more than likely) saved and will become eventually consistent through the well known mechanisms.  I have a case where I would rather this not happen--where I would prefer that if the quorum write fails, that data NEVER becomes consistent, and the old values remain.

After a bit of pondering, I came up the idea of simply making my write a conditional update based on a previous value.  In my use case, I will not be contending with any other writes of the same primary key, and this write operation is rare in the grand scheme of things.  Using this approach, the desired effect is that if the write fails, it will not eventually happen without the app's knowledge.

Is this approach sound?

If so, it sounds like a really cool potential addition to CQL like:  UPDATE tab SET col=? WHERE key=? AUTHORITATIVE

Thoughts?

Wayne

Re: Authoritative failed write: Using paxos to "cancel" failed quorum writes

[Tupshin Harper <tu...@tupshin.com>]

OK, cool.  I can think of no such reason.

-Tupshin
On Mar 11, 2014 10:27 AM, "Wayne Schroeder" <ws...@pinsightmedia.com>
wrote:

>  I think it will work just fine.  I was just asking for opinions on if
> there was some reason it would not work that I was not thinking of.
>
>  On Mar 10, 2014, at 4:37 PM, Tupshin Harper <tu...@tupshin.com> wrote:
>
>  Oh sorry,  I misunderstood. But now I'm confused about how what you are
> trying to do is not accomplished with the existing IF NOT EXISTS syntax.
>
>
> http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_ltwt_transaction_c.html
>
>
>

Re: Authoritative failed write: Using paxos to "cancel" failed quorum writes

[Wayne Schroeder <ws...@pinsightmedia.com>]

I think it will work just fine.  I was just asking for opinions on if there was some reason it would not work that I was not thinking of.

On Mar 10, 2014, at 4:37 PM, Tupshin Harper <tu...@tupshin.com>> wrote:


Oh sorry,  I misunderstood. But now I'm confused about how what you are trying to do is not accomplished with the existing IF NOT EXISTS syntax.

http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_ltwt_transaction_c.html

Re: Authoritative failed write: Using paxos to "cancel" failed quorum writes

[Tupshin Harper <tu...@tupshin.com>]

Oh sorry,  I misunderstood. But now I'm confused about how what you are
trying to do is not accomplished with the existing IF NOT EXISTS syntax.

http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_ltwt_transaction_c.html

-Tupshin
On Mar 10, 2014 4:24 PM, "Wayne Schroeder" <ws...@pinsightmedia.com>
wrote:

>  The plan IS to do the whole write as a lightweight transaction because I
> do need to rely on the behavior.  I am just vetting the expected
> behavior--that doing it as a conditional update, i.e. a light weight
> transaction, that I am not missing something and it will behave as I
> outlined without some other unrealized consequence.  Additionally, it
> sounds like a potential nice CQL level feature -- that a language keyword
> could be added to indicate that a LWT should be done to ensure that the
> quorum update is an all or nothing update at the expense of using LWT.
>
>  Wayne
>
>
>  On Mar 10, 2014, at 3:52 PM, Tupshin Harper <tu...@tupshin.com> wrote:
>
> If you really need to rely on this behavior, you should probably do the
> whole write as a lightweight transaction, despite the additional overhead.
>
>
>

Re: Authoritative failed write: Using paxos to "cancel" failed quorum writes

[Wayne Schroeder <ws...@pinsightmedia.com>]

The plan IS to do the whole write as a lightweight transaction because I do need to rely on the behavior.  I am just vetting the expected behavior--that doing it as a conditional update, i.e. a light weight transaction, that I am not missing something and it will behave as I outlined without some other unrealized consequence.  Additionally, it sounds like a potential nice CQL level feature -- that a language keyword could be added to indicate that a LWT should be done to ensure that the quorum update is an all or nothing update at the expense of using LWT.

Wayne


On Mar 10, 2014, at 3:52 PM, Tupshin Harper <tu...@tupshin.com>> wrote:

If you really need to rely on this behavior, you should probably do the whole write as a lightweight transaction, despite the additional overhead.

Re: Authoritative failed write: Using paxos to "cancel" failed quorum writes

[Tupshin Harper <tu...@tupshin.com>]

Take a 3 node cluster with RF=3, and QUORUM reads and writes. Consistency
is achieved by ensuring that at least two nodes acknowledge a write, and at
least two nodes have to participate in a read. As a result, you know that
at least one of the two nodes that you are reading from has received the
latest copy, and therefore its latest timestamp wins, even if the write
isn't fully propagated to all nodes.

>From a practical point of view, your approach to "cancel" a write would
have to involve the coordinator writing a second deletion mutation after
the first regular mutation in order to effectively cancel it.
The main problem with this is that you can't guarantee it. If the
coordinator fails after the first write goes out but before detecting the
failure, then the write will never be cancelled despite being only
partially written and marked "authoritatiuve"

If you really need to rely on this behavior, you should probably do the
whole write as a lightweight transaction, despite the additional overhead.
If you don't need to rely on this auto-cancelling behavior, I'd strongly
suggest that reacting to a failed write (or at least an exception on write)
 should be better handled in application code.

-Tupshin


On Mon, Mar 10, 2014 at 4:29 PM, Wayne Schroeder <
wschroeder@pinsightmedia.com> wrote:

> As I understand it, even though a quorum write fails, the data is still
> (more than likely) saved and will become eventually consistent through the
> well known mechanisms.  I have a case where I would rather this not
> happen--where I would prefer that if the quorum write fails, that data
> NEVER becomes consistent, and the old values remain.
>
> After a bit of pondering, I came up the idea of simply making my write a
> conditional update based on a previous value.  In my use case, I will not
> be contending with any other writes of the same primary key, and this write
> operation is rare in the grand scheme of things.  Using this approach, the
> desired effect is that if the write fails, it will not eventually happen
> without the app's knowledge.
>
> Is this approach sound?
>
> If so, it sounds like a really cool potential addition to CQL like:
>  UPDATE tab SET col=? WHERE key=? AUTHORITATIVE
>
> Thoughts?
>
> Wayne
>
>