Consistency is Consistently Undervalued

#1

Post by kpmah » Sat, Sep 17, 2016, 7:25 AM UTC

Consistency is Consistently Undervalued
kevinmahoney.co.uk

Re: Consistency is Consistently Undervalued

#2

Post by yyyuuu » Sat, Sep 17, 2016, 8:35 AM UTC

I wandered lonely as a cloud

That floats on high o'er vales and hills,

When all at once I saw a crowd,

A host, of golden daffodils;

Beside the lake, beneath the trees,

Fluttering and dancing in the breeze.

Re: Consistency is Consistently Undervalued

#3

Post by yyyuuu » Sat, Sep 17, 2016, 8:42 AM UTC

Continuous as the stars that shine

And twinkle on the milky way,

They stretched in never-ending line

Along the margin of a bay:

Ten thousand saw I at a glance,

Tossing their heads in sprightly dance.

Re: Consistency is Consistently Undervalued

#4

Post by olalonde » Sat, Sep 17, 2016, 8:48 AM UTC

And in case you think there's a general solution to that problem, there isn't: https://en.wikipedia.org/wiki/CAP_theorem

Still, it's funny how banking seems to be the canonical example for why we need transactions given that most banking transactions are inconsistent (http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on...).

Re: Consistency is Consistently Undervalued

#5

Post by kpmah » Sat, Sep 17, 2016, 8:54 AM UTC

olalonde wrote: post #4

And in case you think there's a general solution to that problem, there isn't: https://en.wikipedia.org/wiki/CAP_theorem Still, it's funny how banking seems to be the canonical example for why we need transactions given that most banking transactions are inconsistent ( http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on... ).

Well, they're eventually consistent. It's not like it hasn't been thought through. :)

It's a useful example because it shows how there can be serious consequences for getting it wrong.

Re: Consistency is Consistently Undervalued

#6

Post by yyyuuu » Sat, Sep 17, 2016, 8:56 AM UTC

kpmah wrote: post #5

olalonde wrote: post #4

And in case you think there's a general solution to that problem, there isn't: https://en.wikipedia.org/wiki/CAP_theorem Still, it's funny how banking seems to be the canonical example for why we need transactions given that most banking transactions are inconsistent ( http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on... ).

Well, they're eventually consistent. It's not like it hasn't been thought through. :) It's a useful example because it shows how there can be serious consequences for getting it wrong.

yes .. you are right

Re: Consistency is Consistently Undervalued

#7

Post by bullen » Sat, Sep 17, 2016, 9:04 AM UTC

But consider this:

You are using mysql, you make a transaction with say deposit and withdraw.

What happens on the mysql machine if you pull the plug exactly when mysql has done the deposit but not the withdraw?

The ONLY difference between SQL transactions and NoSQL microservice transactions is the time between the parts of a transaction.

Personally I use a JSON file with state to execute my NoSQL microservice transactions and it's alot more scalable than having a pre-internet era SQL legacy design hogging all my time and resources.

Re: Consistency is Consistently Undervalued

#8

Post by lomnakkus » Sat, Sep 17, 2016, 9:06 AM UTC

bullen wrote: post #7

But consider this: You are using mysql, you make a transaction with say deposit and withdraw. What happens on the mysql machine if you pull the plug exactly when mysql has done the deposit but not the withdraw? The ONLY difference between SQL transactions and NoSQL microservice transactions is the time between the parts of a transaction. Personally I use a JSON file with state to execute my NoSQL microservice transac…

> What happens on the mysql machine if you pull the plug exactly when mysql has done the deposit but not the withdraw?

Nothing bad -- the deposit will never be seen. It sounds like you need to read up on what ACID means.

(EDIT: Clarification)

Re: Consistency is Consistently Undervalued

#9

Post by XorNot » Sat, Sep 17, 2016, 9:07 AM UTC

bullen wrote: post #7

But consider this: You are using mysql, you make a transaction with say deposit and withdraw. What happens on the mysql machine if you pull the plug exactly when mysql has done the deposit but not the withdraw? The ONLY difference between SQL transactions and NoSQL microservice transactions is the time between the parts of a transaction. Personally I use a JSON file with state to execute my NoSQL microservice transac…

This is not how database transactions work.

A transaction means that the amended state is not visible to any readers until it has been fully committed. Pulling the plug means the transaction is lost, and the writer knows that it was not committed (and so can try again).

Re: Consistency is Consistently Undervalued

#10

Post by hmottestad » Sat, Sep 17, 2016, 9:09 AM UTC

bullen wrote: post #7

But consider this: You are using mysql, you make a transaction with say deposit and withdraw. What happens on the mysql machine if you pull the plug exactly when mysql has done the deposit but not the withdraw? The ONLY difference between SQL transactions and NoSQL microservice transactions is the time between the parts of a transaction. Personally I use a JSON file with state to execute my NoSQL microservice transac…

>> What happens on the mysql machine if you pull the plug exactly when mysql has done the deposit but not the withdraw?

Nothing happens. And the client discovers that the connection to the db was closed before the 2 phase commit was done and gives an error to the user.