Clarification on “Call Me Maybe: MariaDB Galera Cluster”
1–10 of 73 posts
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#2> If you use this in a real life, the more obvious way to write these transactions is:
Is it? Do ORMs really do that, or is it one of those "SQL was designed to be used this way, but nobody using SQL read the design documents" cases?
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#3I do not quite like the usage of the word “corrupted” here. For me, the more correct word be to use is “inconsistent”.
Aren't we talking about situations in which a database tracking account balances creates money out of thin air, or vaporizes it unexpectedly?
I feel like Aphyr is always at pains to talk about the real-world implications of these findings --- not just how bad they are in sensitive applications, but also the kinds of places you can get away with these "inconsistencies".
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#4I do not quite like the usage of the word “corrupted” here. For me, the more correct word be to use is “inconsistent”. Aren't we talking about situations in which a database tracking account balances creates money out of thin air, or vaporizes it unexpectedly? I feel like Aphyr is always at pains to talk about the real-world implications of these findings --- not just how bad they are in sensitive applications, but a…
It is an inconsistency, and inconsistencies are very bad. Calling it something else won't help.
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#5> If you use this in a real life, the more obvious way to write these transactions is: Is it? Do ORMs really do that, or is it one of those "SQL was designed to be used this way, but nobody using SQL read the design documents" cases?
Good point, but imho anyone that relies on transactionnal properties to ensure validity of its operation should really not be using ORMs ( at least not for the sensitive operations).
You shouldn't need to read an ORM documentation to understand what kind of locking is happening at a given time. It should all be there right in your code.
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#6I do not quite like the usage of the word “corrupted” here. For me, the more correct word be to use is “inconsistent”. Aren't we talking about situations in which a database tracking account balances creates money out of thin air, or vaporizes it unexpectedly? I feel like Aphyr is always at pains to talk about the real-world implications of these findings --- not just how bad they are in sensitive applications, but a…
A database maker would say it isn't the database that created the money out of thin air, but the faulty application code that didn't select the right isolation level.
Of course, whether it's wise for a database to default to anything except Serializable isolation is another matter.
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#7I do not quite like the usage of the word “corrupted” here. For me, the more correct word be to use is “inconsistent”. Aren't we talking about situations in which a database tracking account balances creates money out of thin air, or vaporizes it unexpectedly? I feel like Aphyr is always at pains to talk about the real-world implications of these findings --- not just how bad they are in sensitive applications, but a…
Yeah, I found it strange that he says "it's not X, it's Y" but doesn't define either one himself.
My own definitions would agree with him: corrupted - you get exception while trying to read, or meaningless data; inconsistent - you get the right types, but wrong values. But I can only guess if his definitions agree with mine by accident, or are the same.
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#8> If you use this in a real life, the more obvious way to write these transactions is: Is it? Do ORMs really do that, or is it one of those "SQL was designed to be used this way, but nobody using SQL read the design documents" cases?
[deleted]
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#9> If you use this in a real life, the more obvious way to write these transactions is: Is it? Do ORMs really do that, or is it one of those "SQL was designed to be used this way, but nobody using SQL read the design documents" cases?
Good point, but imho anyone that relies on transactionnal properties to ensure validity of its operation should really not be using ORMs ( at least not for the sensitive operations). You shouldn't need to read an ORM documentation to understand what kind of locking is happening at a given time. It should all be there right in your code.
This approach only works if your logic is codable in SQL format in the way this trivial balance change can be. If the change is happening in app business logic, this is always going to be a problem.
The fact the balance+=25 type approach works is kind of a hack, and I don't think Aphyr is wrong to call it "corrupted" (in this specific example, in one transaction, you could say that it is inconsistent - but you only need a few inconsistent operations in the same place and suddenly your data is complete rubbish).
This feels a bit like handwaving the problem away, to me. Yes, InnoDB has the problem, but with that backend you can set SERIALIZABLE isolation. You can't do that in Galera. So if you don't have the option of rewriting the SQL (either because it's not your SQL, or there is no SQL alternative available) then you're screwed.
Re: Clarification on “Call Me Maybe: MariaDB Galera Cluster”
#10> If you use this in a real life, the more obvious way to write these transactions is: Is it? Do ORMs really do that, or is it one of those "SQL was designed to be used this way, but nobody using SQL read the design documents" cases?
They don't do that automatically. In sqlalchemy for example you still have to call an extra function explicitly. (http://docs.sqlalchemy.org/en/rel_0_9/changelog/migration_09...) I know of only one developer who knew about "for update", but then again they just read the mysql book with chapter dedicated to locking behaviour.