A critique of ANSI SQL isolation levels
SIGMOD '95 Proceedings of the 1995 ACM SIGMOD international conference on Management of data
Semantic Conditions for Correctness at Different Isolation Levels
ICDE '00 Proceedings of the 16th International Conference on Data Engineering
A read-only transaction anomaly under snapshot isolation
ACM SIGMOD Record
Ganymed: scalable replication for transactional web applications
Proceedings of the 5th ACM/IFIP/USENIX international conference on Middleware
Postgres-R(SI): Combining Replica Control with Concurrency Control Based on Snapshot Isolation
ICDE '05 Proceedings of the 21st International Conference on Data Engineering
Allocating isolation levels to transactions
Proceedings of the twenty-fourth ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems
Middleware based data replication providing snapshot isolation
Proceedings of the 2005 ACM SIGMOD international conference on Management of data
Making snapshot isolation serializable
ACM Transactions on Database Systems (TODS)
Database Replication Using Generalized Snapshot Isolation
SRDS '05 Proceedings of the 24th IEEE Symposium on Reliable Distributed Systems
Lazy database replication with snapshot isolation
VLDB '06 Proceedings of the 32nd international conference on Very large data bases
Automating the detection of snapshot isolation anomalies
VLDB '07 Proceedings of the 33rd international conference on Very large data bases
The Cost of Serializability on Platforms That Use Snapshot Isolation
ICDE '08 Proceedings of the 2008 IEEE 24th International Conference on Data Engineering
Hi-index | 0.00 |
Snapshot Isolation concurrency control (SI) allows substantial performance gains compared to holding commit-duration readlocks, while still avoiding many anomalies such as lost updates or inconsistent reads. However, for some sets of application programs, SI can result in non-serializable execution, in which database integrity constraints can be violated. The literature reports two different approaches to ensuring all executions are serializable while still using SI for concurrency control. In one approach, the application programs are modified (without changing their stand-alone semantics) by introducing extra conflicts. In the other approach, the application programs are not changed, but a small subset of them must be run using standard two-phase locking rather than SI. We compare the performance impact of these two approaches. Our conclusion is that the convenience of preserving the application code (and adjusting only the isolation level for some transactions) leads to a very substantial performance penalty against the best that can be done through application modification.