Serializable executions with snapshot isolation: modifying application code or mixing isolation levels?

  • Authors:
  • Mohammad Alomari;Michael Cahill;Alan Fekete;Uwe Röhm

  • Affiliations:
  • The University of Sydney, School of Information Technologies, Sydney, NSW, Australia;The University of Sydney, School of Information Technologies, Sydney, NSW, Australia;The University of Sydney, School of Information Technologies, Sydney, NSW, Australia;The University of Sydney, School of Information Technologies, Sydney, NSW, Australia

  • Venue:
  • DASFAA'08 Proceedings of the 13th international conference on Database systems for advanced applications
  • Year:
  • 2008

Quantified Score

Hi-index 0.00

Visualization

Abstract

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.