This is great, really worth reading if you're interested in transactions.
I liked it so much I wrote up how the model applies to Amazon Aurora DSQL at https://brooker.co.za/blog/2025/04/17/decomposing.html It's interesting because of DSQL's distributed nature, and the decoupling between durability and application to storage in our architecture.
> commit version is chosen — the time at which the database claims all reads and writes occurred atomically.
This post doesn't mention transaction isolation specifically though it does say "How does this end up being equal to SERIALIZABLE MySQL?" So maybe I'm supposed to consider this post only for 'Every transactional system' running with SERIALIZABLE transaction isolation. I don't particularly care about that. I do care that the database I use clearly states what its isolation names mean in detail and that it does exactly what it says. e.g. I don't expect MySQL SERIALIZABLE to exactly mean the same as any other database that uses the same term.
MySQL Serializable is pretty similar to serializable in other databases, in terms of the observable anomalies. There's a good set of tests here: https://github.com/ept/hermitage
> So maybe I'm supposed to consider this post only for 'Every transactional system' running with SERIALIZABLE transaction isolation.
No, it's a general point about the nature of transactions in DBMSs, and the different implementation choices. As the article says, there are some variations (e.g. MVCC at levels lower than serializable inherently has two 'order' steps).
I'm not seeing the mention of two 'order' steps. Are you referring to the larger part of what I quoted?
> MVCC databases may assign two versions: an initial read version, and a final commit version. In this case, we’re mainly focused on the specific point at which the commit version is chosen — the time at which the database claims all reads and writes occurred atomically.
For non-SERIALIZABLE isolation there may be no such "time at which the database claims all reads and writes occurred atomically", which is how I took the rest of the post to mean when running with SERIALIZABLE isolation.
This is great, really worth reading if you're interested in transactions.
I liked it so much I wrote up how the model applies to Amazon Aurora DSQL at https://brooker.co.za/blog/2025/04/17/decomposing.html It's interesting because of DSQL's distributed nature, and the decoupling between durability and application to storage in our architecture.
> commit version is chosen — the time at which the database claims all reads and writes occurred atomically.
This post doesn't mention transaction isolation specifically though it does say "How does this end up being equal to SERIALIZABLE MySQL?" So maybe I'm supposed to consider this post only for 'Every transactional system' running with SERIALIZABLE transaction isolation. I don't particularly care about that. I do care that the database I use clearly states what its isolation names mean in detail and that it does exactly what it says. e.g. I don't expect MySQL SERIALIZABLE to exactly mean the same as any other database that uses the same term.
MySQL Serializable is pretty similar to serializable in other databases, in terms of the observable anomalies. There's a good set of tests here: https://github.com/ept/hermitage
> So maybe I'm supposed to consider this post only for 'Every transactional system' running with SERIALIZABLE transaction isolation.
No, it's a general point about the nature of transactions in DBMSs, and the different implementation choices. As the article says, there are some variations (e.g. MVCC at levels lower than serializable inherently has two 'order' steps).
I'm not seeing the mention of two 'order' steps. Are you referring to the larger part of what I quoted?
> MVCC databases may assign two versions: an initial read version, and a final commit version. In this case, we’re mainly focused on the specific point at which the commit version is chosen — the time at which the database claims all reads and writes occurred atomically.
For non-SERIALIZABLE isolation there may be no such "time at which the database claims all reads and writes occurred atomically", which is how I took the rest of the post to mean when running with SERIALIZABLE isolation.