  The support for transactions is an essential part of a database management
system (DBMS). Without this support, the developers are burdened with ensuring
atomic execution of a transaction despite failures as well as concurrent
accesses to the database by other transactions. Ideally, a transactional system
provides serializability, which means that the outcome of concurrent
transactions is equivalent to a serial execution of them. Based on experiences
on lock-based implementations, nevertheless, serializability is known as an
expensive feature that comes with high overhead and low concurrency. Commercial
systems, hence, compromise serializability by implementing weaker guarantees
such as snapshot isolation. The developers, therefore, are still burdened with
the anomalies that could arise due to the lack of serializability.
  There have been recent attempts to enrich large-scale data stores, such as
HBase and BigTable, with transactional support. Not surprisingly, inspired by
traditional database management systems, serializability is usually compromised
for the benefit of efficiency. For example, Google Percolator, implements
lock-based snapshot isolation on top of BigTable. We show in this paper that
this compromise is not necessary in lock-free implementations of transactional
support. We introduce write-snapshot isolation, a novel isolation level that
has a performance comparable with that of snapshot isolation, and yet provides
serializability. The main insight in write-snapshot isolation is to prevent
read-write conflicts in contrast to write-write conflicts that are prevented by
snapshot isolation.
