2 ms·

I feel like this article is using strange definitions - ones that may be common, but are also incorrect. There's an example, about halfway through, of a custome

I feel like this article is using strange definitions - ones that may be common, but are also incorrect. There's an example, about halfway through, of a customer withdrawing $20 twice in different regions from the same bank account. The definition of "serializable" that the author is using includes the following flow: A | B Reads $50 | |Reads $50 Writes $30| |Writes $30 This was a bug, and a huge one in either the application or the database. On one hand, the application should have sent the SQL statements: A | B Acct = |Acct = Acct - $20|Acct - $20 Or the whole thing should have been wrapped in a transaction, so no interleaving of A and B would have been permitted. Either is fine. If the database had not dealt with either, it would have been incorrect. Of course, even better, and actually a requirement of proper financial systems: Write the whole thing as a ledger and archive the results. SQL databases do actually make this easy, if you archive your Write-ahead-logs. NoSql makes this easy to write and write verification tools for. The argument about which is better belongs to implementers, and to fools - the fools who do not verify correctness of their data regularly.

mjb 7y ago
That's part of the point he's making, though. To reject this case in a distributed database needs some additional concepts. From the article: > Whichever transaction is second --- when it reads the balance --- it must read the value written by the first transaction. Attar et. al. named this guarantee “one copy serializability” or “1SR”, because the isolation guarantee is equivalent to serializability in an unreplicated system with “one copy” of every data item. Your point about archiving logs assumes there is one log of transactions, which isn't true in general in distributed databases (although something equivalent to one log needs to exist for 1SR).

mjb 7y ago

That's part of the point he's making, though. To reject this case in a distributed database needs some additional concepts. From the article: > Whichever transaction is second --- when it reads the balance --- it must read the value written by the first transaction. Attar et. al. named this guarantee “one copy serializability” or “1SR”, because the isolation guarantee is equivalent to serializability in an unreplicated system with “one copy” of every data item. Your point about archiving logs assumes there is one log of transactions, which isn't true in general in distributed databases (although something equivalent to one log needs to exist for 1SR).