Database Replication Using Generalized Snapshot Isolation∗ Sameh Elnikety Fernando Pedone Willy Zwaenepoel School of Computer and Faculty of Informatics School of Computer and Communication Sciences Universita` della Svizzera Italiana Communication Sciences EPFL USI EPFL Lausanne, Switzerland Lugano, Switzerland Lausanne, Switzerland service because if a replica fails, information can still be Abstract accessed at other replicas. In a centralized dynamic content Web site, the dynamic data is most often stored in a database Generalized snapshot isolation extends snapshot isola- [8, 3]. Therefore, one of the key problems in replicating dy- tion as used in Oracle and other databases in a manner suit- namic Web content generation is replicating the database able for replicated databases. While (conventional) snap- and keeping the replicas consistent. shot isolation requires that transactions observe the “lat- Ideally, we would like to provide the same database con- est” snapshot of the database, generalized snapshot iso- sistency as in the centralized database case. We focus here lation allows the use of “older” snapshots, facilitating a on databases providing snapshot isolation [6]. In such a replicated implementation. We show that many of the de- database, a transaction T obtains at the beginning of its ex- sirable properties of snapshot isolation remain. In particu- ecution the latest snapshot of the database, reflecting the lar, read-only transactions never block or abort and they do writes of all transactions that have committed before trans- not cause update transactions to block or abort. Moreover, action T starts. At commit, the database checks that the under certain assumptions on the transaction workload the writeset of transaction T does not intersect with the write- execution is serializable. sets of the transactions that committed since T ’s snapshot. An implementation of generalized snapshot isolation can If there is a non-zero intersection, transaction T aborts; oth- choose which past snapshot it uses. An interesting choice erwise, it commits. for a replicated database is prefix-consistent snapshot isola- Snapshot isolation is popular for a number of reasons, tion, in which the snapshot contains at least all the writes of one of which is the pragmatic reason that Oracle [9, 20] locally committed transactions. We present two implemen- and other database vendors [25, 32, 19] use it. More funda- tations of prefix-consistent snapshot isolation. We conclude mentally, snapshot isolation never requires read-only trans- with an analytical performance model of one implementa- actions to block or abort, and read-only transactions do not tion, demonstrating the benefits, in particular reduced la- cause update transactions to block or abort. This advantage tency for read-only transactions, and showing that the po- is significant for workloads with a large fraction of read- tential downsides, in particular change in abort rate of up- only transactions (such as those resulting from the gener- date transactions, are limited. ation of dynamic Web content). Snapshot isolation pro- vides a weaker form of consistency than serializability, but one that programmers can understand and use. Moreover, 1. Introduction Fekete et al. [11, 13] have recently demonstrated that under certain conditions on the workload transactions executing There is increasing interest in replicating the generation on a database with snapshot isolation produce serializable of dynamic Web content [2, 14] for many Web services to histories. achieve efficiency and fault tolerance. The user’s request is executed on a “nearby” replica, thereby avoiding long 1.1. Generalized Snapshot Isolation (GSI) roundtrip delays and distributing the load over the replicas. In addition, replication increases the availability of a Web Extending snapshot isolation to replicated databases is not straightforward. Intuitively, the problem stems from the ∗This research was partially supported by the Swiss National Science Foundation grant number 200021-107824: System Support for Distributed requirement that a transaction must see the “latest” snap- Dynamic Content Web Services. shot when it starts execution. In contrast with the central- ized case, the notion of “latest” is not a priori well-defined 1.3. Contributions in a distributed setting. Implementations of an ordering that defines the notion of “latest” and makes the corresponding The contributions of this paper are as follows: (1) intro- snapshot available may impose a delay at the start of a trans- ducing generalized snapshot isolation, (2) establishing two action. Imposing such a delay at the beginning of read-only sufficient conditions (one dynamic condition and one stat- transactions voids one of the main benefits of snapshot iso- ically checkable condition) that guarantee serializable exe- lation. cution under generalized snapshot isolation, (3) introducing Generalized snapshot isolation is based on the observa- prefix-consistent snapshot isolation and two implementa- tion that a transaction need not necessarily observe the “lat- tion strategies for replicated databases, and (4) analytically est” snapshot. It can observe an older snapshot, and many characterizing the relative performance of prefix-consistent properties as those in (conventional) snapshot isolation con- snapshot isolation to conventional snapshot isolation. tinue to hold. Conditions can be identified that guarantee se- rializable execution. With a suitable choice of “older”, read- 1.4. Roadmap only transactions execute without delay or aborts, and they do not cause update transactions to block or abort. Trans- This paper is organized as follows: We present the actions may, however, observe somewhat older data. To database model in Section 2 and develop generalized snap- commit an update transaction, its writeset must be checked shot isolation in Section 3. Then we discuss how to guaran- against the writesets of recently committed transactions, as tee serializability in Section 4, and provide a dynamic and before. The probability of an abort increases, as it becomes a static condition for serializability under generalized snap- more likely that at the time of its commit an update trans- shot isolation. action finds that another transaction has written to the same In section 5, we present prefix-consistent snapshot iso- data as it did since the time of its snapshot. lation, which is an instance of generalized snapshot iso- lation that is suitable for replicated databases. In section The ability to start from an older snapshot gives rise to 6, we present a model for a distributed system with repli- an interesting spectrum of possibilities with attendant per- cated databases. We first show that conventional snapshot formance tradeoffs. At one end of the spectrum is the con- isolation must impose a delay on read-only transactions in ventional notion of snapshot isolation, further referred to in that model, and then we develop two algorithms that imple- this paper as conventional snapshot isolation, in which each ment prefix-consistent snapshot isolation , one using cen- transaction reads the latest snapshot. This is clearly appro- tralized certification and the other using distributed certi- priate in a centralized setting where the latest snapshot is fication. In Section 7, we compare analytically the per- trivially available, and where using the latest snapshot min- formance of prefix-consistent snapshot isolation to conven- imizes the probability of aborts. At the other end of the tional snapshot isolation. Finally, we discuss related work spectrum is the trivial solution in which all transactions ob- in Section 8 and derive our conclusions and future research serve the initial snapshot (i.e., the database state as in the directions in Section 9. beginning of execution). We omit the proofs of propositions and of correctness of the algorithms due to space limitations. We, however, provide all proofs in a technical report [10]. 1.2. Prefix-Consistent Snapshot Isolation (PCSI) 2. Database Model and Definitions In a replicated setting, an interesting positioning in this 2.1. Database Model spectrum is for a transaction to take as its initial snapshot the latest snapshot that is locally available on its replica. We assume that a database is a collection of uniquely We capture this idea in prefix-consistent snapshot isolation. identified data items. Several versions of each data item As an instance of generalized snapshot isolation, prefix- may co-exist simultaneously in the database, but there is a consistent snapshot isolation maintains the desirable prop- total order among the versions of each data item. A snap- erties of generalized snapshot isolation. Read-only trans- shot of the database is a committed state of the database. actions never block or abort, and they do not cause update A transaction Ti is a sequence of read and write oper- transactions to block or abort. Moreover, transactions ob- ations on data items, followed by either a commit or an serve at least all the writes that have committed on the lo- abort operation. We denote Ti’s write operation on item cal replica before they start. This property is important in X by Wi(Xi). If Ti executes Wi(Xi) and commits, then a a workflow of transactions, in which a user submits a se- new version of X, denoted by Xi, is added to the database. quence of transactions to a replica. Moreover, we denote Ti’s read operation on item Xj by Ri(Xj). Ti’s commit or abort is denoted by Ci or Ai, re- From this definition, only committed update transactions spectively. Finally, to simplify the presentation, we assume may impact update transaction Ti. Read-only transactions that transactions do not contain redundant read or write op- and uncommitted transactions cannot impact Ti. When 1 erations : A transaction reads any item at most once and committing an active update transaction Ti, we say “Tj im- writes any item at most once, and if a transaction writes an pacts Ti” to mean that if Ti were to commit now, then Tj item, it does not read that item afterwards. would impact Ti. A transaction is read-only if it contains no write oper- ation, and is update otherwise.