3 ms·
> Serializable and snapshot are indistinguishable for read-only transactions, no? No. See "A read-only transaction anomaly under snapshot isolation" [1]. [1]
by pulisse 3y ago
> Serializable and snapshot are indistinguishable for read-only transactions, no?
No. See "A read-only transaction anomaly under snapshot isolation" [1].
[1] https://dl.acm.org/doi/10.1145/1031570.1031573 https://dl.acm.org/doi/10.1145/1031570.1031573
- karmakaze 3y ago> we exhibit an example contradicting these assumptions: it is possible for an SI [snapshot isolation] history to be non-serializable while the sub-history containing all update transactions is serializable. Do you know what this case is? It could be a truth that won't matter to many/most of us--perhaps good to know, but no reason to stop everything. I don't particularly care as DBs I work with have been Repeatable Read or Read Committed. It was demonstrated on an Oracle database and it's unclear if it would apply to others.
- deleted 3y ago[deleted]
- orlp 3y agoI see, that is a tricky case. When serializability would have required a transaction order that is different from commit order for two transactions, inserting a third snapshot-isolated read in between can violate the (logical) reordering of the write transactions needed to justify serializability.