[hyperpape]

> According to the paper, “Of the 22 vulnerabilities, five were level-based, meaning that the default weak isolation level led to the anomalies behind the vulnerabilities. The remaining 17 were scope-based, meaning that the database accesses were not properly encapsulated in transactions and concurrent API requests could trigger the vulnerability independent of the level of isolation provided by the database backend.”

I don't want to commit to a real opinion, but the cynic in me sees a bitter lesson you could take from this is that the database should default to a low isolation level--the damn developers aren't even using transactions right, so why waste performance handling transactions in the strictest possible way?

[klodolph]

My experience is that there’s a percentage of developers who get it right and intuitively understand the serializable isolation level.

And database performance is a crapshoot. By “crapshoot”, I mean you mix some developers, data, and database technologies together and you get all sorts of weird performance profiles. Why sacrifice safety for performance, when you’re going to get performance problems anyway? It’s a lot easier to turn down the isolation level for a transaction, and it’s a lot harder to fix an unknown amount of inconsistent data in your database.

(The problem is that there are also a big cohort of developers who aren’t prepared to make their transactions retryable, and they’re writing their code in languages which don’t enforce transaction safety. By “languages which don’t enforce transaction safety”, I mean “languages other than Haskell”.)

[onlyrealcuzzo]

So every database in the world not designed in Haskell can't do a proper transaction?

[mrkeen]

It's not the database, it's the lines of code making calls to the database.

If you're invoking your DB via C code, you will not get help with memory-safety. If you're invoking via non-Haskell code, you won't get help with transaction safety.

[onlyrealcuzzo]

> If you're invoking your DB via C code, you will not get help with memory-safety.

Interesting. I didn't know C and Haskell were the only languages. I thought for sure there was at least one other memory safe language.

> If you're invoking via non-Haskell code, you won't get help with transaction safety.

Why would you not use transactions built into the database?!

You still did not answer the question...

If you can't do a transaction safely in any language besides Haskell... Then how do databases not written in Haskell do them all day everday?

[zadikian]

The "transaction safety" part is confusing. What they mean is if you use SERIALIZABLE, transactions need to be retried, so your code inside the xact should be idempotent. I guess this is safer in Haskell because there are no variables, but that doesn't stop your code from having other side effects.

[mrkeen]

>>>> they’re writing their code in languages which don’t enforce transaction safety

>>> So every database in the world not designed in Haskell can't do a proper transaction?

>> It's not the database, it's the lines of code making calls to the database.

> Then how do databases not written in Haskell do them all day everday?

[stubish]

Too many people discovered databases with MySQL back in the day and didn't even know transactions were possible. And now 25 years later one of those people is likely a senior dev and 'the db guy' on a team of people who learn SQL by example. Or now never learnt it, relying on an LLM trained on decades of dodgy PHP code.

[vlovich123]

That’s the same mentality C and C++ take. Even if it was only 20%, that’s a non trivial amount of vulnerabilities that have nothing to do with the code.