3 ms·
> Their banking example is impossible under any system which guarantees serializability. > > To guarantee serializability, the database system cannot assume any
by ascar 8y ago
> Their banking example is impossible under any system which guarantees serializability.
>
> To guarantee serializability, the database system cannot assume anything about how some value is derived
Their example is very well possible with a system that just guarantees serializability. Especially if it's distributed. The database is not assuming anything in their example, but you are changing the database design and assume it's in a way serializability works. Serializability works in many scenarios, especially on single machine databases, that's why it was usually sufficient (they even mention exactly that). So it's very easy to come up with an example for serializability working. Actually your example is equivalent to their first example (with inventory), where they point out how serializability works.
But the data in their second example is not in a single value "money", but it's disjoint values "savings_balance" and "checkings_balance". Reads/writes to these are from a database point of view non-conflicting operations, so they might be reordered. The article explains the transactions access disjoint data (checking balance vs savings balance) if the disjoint data are located on different machines in a distributed system.
So the two transactions T1 (add money to saving) and T2 (remove money from checkings), may be executed T1 -> T2 and T2 -> T1, because they are non-conflicting reads/writes. In the T2 -> T1 case of their example, the balance dropped below $5000 dollar, because the addition came later.
- tirumaraiselvan 8y agoExcept in that case, the user already received confirmation that T1 was success before T2 was even executed. So not sure how that is even possible.
- ht85 8y agoThe confirmation is coming from one of the database nodes but T2 might be executed on a different node, where T1 hasn't been replicated yet.
- tirumaraiselvan 8y agoThat seems like a problem of not having sync acknowledgements while allowing multi-instance writes at the same time. I am not sure if that is a strict serializability issue anymore.
- freels 8y agoThe constraint that all observers see T1 before T2 because T1 is acknowledged before T2 begins is the “in real time” component of a strict serializability guarantee. Mere serializability does not guarantee this, as unintuitive as that sounds. Jepsen.io has a good explainer: https://jepsen.io/consistency/models/serializable https://jepsen.io/consistency/models/serializable
- slaymaker1907 8y agoANSI SQL serializable is not the same as serializability in a mathematical sense. The standard defined serializability in terms of anomalies since they came up with the standard without considering things like snapshot isolation or MVCC. The classic example, related to mine, which shows the difference is with the following two queries: update balls set color=0 where color=1; update balls set color=1 where color=0; Under (mathematical) serializability, all the balls must be the the same color. However, under snapshot isolation (serializable according to the SQL standard), it is also possible to just have the colors swapped in case both queries read the same version. You can verify it yourself, but this is not any one of the typical anomalies since both transactions neither read nor write to the same rows. A phantom read does not occur since each transaction only does a single read operation.