A Read-Only Transaction Anomaly Under Snapshot Isolation By Alan Fekete, Elizabeth O'Neil, and Patrick O'Neil [email protected], {eoneil, poneil}@cs.umb.edu Research of all authors was supported by NSF Grant IRI 97-11374.

Abstract. Snapshot Isolation (SI), The interval in time from the start is a multi-version to the commit of a transaction, repre- algorithm introduced in [BBGMOO95] and sented [Start(Ti), Commit(Ti)], is later implemented by Oracle. SI avoids called its transactional lifetime. We many concurrency errors, and it never say two transactions T1 and T2 are delays read-only transactions. However concurrent if their transactional it does not guarantee . lifetimes overlap, i.e., [start(T1), It has been widely assumed that, under commit(T1)] ∩ [start(T2), commit(T2)] SI, read-only transactions always exe- ≠ Φ. Writes by transactions active cute serializably provided the concur- after T starts, i.e., writes by rent update transactions are serializ- i able. The reason for this is that all concurrent transactions, are not visi- SI reads return values from a single ble to Ti. When Ti is ready to commit, instant of time when all committed it obeys the First Committer Wins transactions have completed their rule, as follows: Ti will successfully writes and no writes of non-committed commit if and only if no concurrent transactions are visible. This seems transaction Tk has already committed to imply that read-only transactions writes (updates) of rows or index will not read anomalous results so entries that Ti intends to write. See long as the update transactions with also the discussion of the variant which they execute do not write such First Updater Wins rule below. results. In the current note, however, The First Committer Wins rule is we exhibit an example contradicting reminiscent of certification in optim- these assumptions: it is possible for istic concurrency control, but only an SI history to be non-serializable items written by Ti are checked for while the sub-history containing all concurrent modification, not items update transactions is serializable. read. In the Oracle implementation of 1. Definition of Snapshot Isolation Snapshot Isolation (referred to as the In what follows, we assume time is SERIALIZABLE Isolation Level in Oracle measured by a counter that advances [JAC95]), an attempt by Ti to read a whenever any transaction starts or row that has changed since start(Ti) commits, and we designate the time will cause the system to read an ap- when transaction Ti starts as propriate older version in the roll- start(Ti) and the time when Ti commits back segment. Indexes are also ac- as commit(Ti). cessed in the appropriate snapshot Definition 1.1: Snapshot Iso- state, so that predicate evaluation lation (SI). A transaction Ti exe- retrieves row versions current as of cuting under SI conceptually reads the snapshot. The First Committer Wins data from the committed state of the rule is enforced, not by a commit-time validation, but by checks done at the as of time start(Ti) (the snapshot), and holds the results of time of updating. If Ti and Tk are its own writes in local memory store, concurrent, and Ti updates the data so if it reads data it has written it item X, then it will take a Write lock will read its own output. Predicates on X; if Tk subsequently attempts to evaluated by Ti are also based on rows update X while Ti is still active, Tk and index entry versions from the com- will be prevented by the lock on X mitted state of the database at time from making further progress. If Ti start(Ti), adjusted to take Ti's own then commits, Tk will abort; Tk will writes into account. Snapshot Isola- only be able to continue if Ti drops tion also must obey a "First Committer its lock on X by aborting. If, on the (Updater) Wins" rule, explained below• other hand, Ti and Tk are concurrent,

-1- and Ti updates X but then commits be- to the READ COMMITTED isolation level, fore Tk attempts to update X, there which takes long-term write-locks but will be no delay due to locking, but no long-term read locks (it only tests Tk will abort immediately when it at- reads to make sure they do not read tempts to update X (the abort does not write-locked data); in that case, the history above without the versioned wait until Tk attempts to commit). For Oracle we rename the First Committer data items would succeed in both its Wins rule to First Updater Wins; the writes, causing a Lost Update. • ultimate effect is the same – one of the concurrent transactions updating a Despite its attractions, SI does not data item aborts. Aborts by a transac- ensure that all executed histories are tion for this reason are known as se- serializable, as defined in classical rialization errors, ORA-08177 (Oracle transactional theory (e.g., in [BHG87, Release 9.2). PAPA86, GR93]). Indeed it is possible Snapshot Isolation is an attractive for a set of transactions, each of isolation level. Reading from a snap- which in isolation respects an integ- shot means that a transaction never rity constraint, to execute under SI sees the partial results of other in such a way as to leave the database transactions: T sees all the changes in a corrupted state. One such problem made by transactions that commit be- is called "Write Skew". fore start(T), and it sees no changes made by transactions that commit after Example 1.2. Write Skew. Suppose X start(T). Also, the First Committer and Y are data items in different rows Wins rule allows SI to avoid the most representing checking account balances common type of lost update error, as of a married couple at a bank, with a shown in Example 1.1. constraint that X+Y > 0 (the bank per- mits either account to be overdrawn, 2. Anomaly Behavior in SI as long as the sum of the account bal- Most of the anomalies that occur in ances remains positive). Assume that lower Locking Isolation Levels such as initially X0 = 70 and Y0 = 80. Under READ COMMITTED are absent in SI. SI, transaction T1 reads X0 and Y0, Example 1.1 gives an example. then subtracts 100 from X, assuming it is safe because the two data items Example 1.1. Lost Update. If added up to 150. Transaction T2 con- transaction T1 tries to modify a data currently reads X0 and Y0, then sub- tracts 100 from Y, assuming it is safe item X while a concurrent T2 also tries to modify X, then SI's First for the same reason. Each update is Committer Wins rule will cause one of safe by itself, but SI will result in the transactions to abort, so the the following history: first update will not be lost. E.g., in example history H1 below, we dis- H2: R1(X0,70) R2(X0,70) R1(Y0,80) play the values read and written in a R2(Y0,80) W1(X1,-30) C1 W2(Y2,-20) C2 versioned notation we use to specify Here the final committed state (X1 and SI histories; when Ti writes a version of X, the version is named X . Y2) violates the constraint X+Y > 0. i This problem was not detected by First Committer Wins because two different H1: R (X0,50) R (X0,50) W (X2,70) C 1 2 2 2 data items were updated, each under W1(X1,60) A1 the assumption that the other remained stable. Hence the name "Write Skew". • This history leaves X with the value 70 (version X2), since only T2, at- While Example 1.2 displays one of a tempting to add an increment of 20 to number of anomalous situations that X, was able to complete. T1 can now can arise in SI, the occurrence of retry and hopefully add its increment such situations is actually rather of 10 to X without interference. Note rare in real-world applications. The that many database system products TPC-C benchmark application [TPC-C], with locking-based concurrency default consisting of seven transactional pro-

-2- grams, displays no such anomalies, and if X+Y goes negative; finally, T3 is a it is reasonably representative. We read-only transaction that retrieves also point out that it is quite easy the values of X and Y and prints them to modify application or database de- out for the customer. For one sequence sign to avoid the anomaly of Example of operations, this can result in the 1.2. One way is to require in the following history under SI: transactional program that each Read of X and Y to update Y give the im- H3: R2(X0,0) R2(Y0,0) R1(Y0,0) pression of a Write of X (this is pos- W1(Y1,20) C1 R3(X0,0) R3(Y1,20) C3 sible in Oracle using the Select For W2(X2,-11) C2 Update statement). Now it seems that both X and Y are updated in H2 and The anomaly that arises in this trans- collision will occur. Another approach action is that read-only transaction requires that each constraint on the T prints out X = 0 and Y = 20, while sum of two accounts X and Y be materi- 3 final values are Y = 20 and X = -11. alized in another row Z and insist This can’t happen in any serializable that all updates of X and Y must keep execution since if 20 was added to Y Z up to date. Then the anomaly of his- before 10 was subtracted from X, no tory H will not arise, since collision charge of 1 would ever occur, and the on updates of Z will occur whenever X final balance should be 10, not 9. A and Y are updated by two different customer, knowing a deposit of 20 was transactions. due and worried that his check for 10 might have caused a penalty, would 3. A Read-Only Transaction conclude he was safe based on the data Anomaly in SI read by T3. Indeed, such a print-out Another type of anomaly can occur re- by T3 would be embarrassing for a bank sulting from read-only transaction should the SEC ask how the charge oc- participation. As we explained in the curred. We also note that any execu- Abstract, this is surprising. Starting tion of T1 and T2 (with arbitrary pa- with [BBGMOO95], it was assumed that rameter values) without T3 present read-only transactions always execute will always act serializably. • serializably, without ever needing to wait or abort because of concurrent Intuitive Explanation of Example update transactions. This seemed self- 1.3. In H3, T2 reads X0 = 0 and Y0 = evident because all reads take place 0, then writes X2 = -11, while T1 con- at an instant of time, when all com- currently updates Y1 to hold 20, which mitted transactions have completed would change the behavior of T2 if T2 their writes and no writes of non-com- started after T1 committed. The only mitted transactions are visible. The equivalent serial history ending with implied guarantee is that read-only X = -11 and Y = 20 must have T2 fol- transactions will not read anomalous lowed by T1. But since concurrent results so long as the update transac- transactions don't see each other's tions do not write such results. But results in SI, T can commit first Example 1.3 shows this isn't true. 1 (out of serial order). Now the read- only transaction T can see the com- Example 1.3. Read-Only Transac- 3 tion Anomaly. Suppose X and Y are mitted state of T1 only: Y = 20, and X data items in different rows repre- = 0, and conclude that the deposit senting a checking account balance and came in before the charge, implying a savings account balance, and that there would be no penalty charge when initially X0 = 0 and Y0 = 0. In his- T2 executes. The fact that SI allows commit order different than serial tory H3 below, transaction T1 deposits order is what causes the anomaly. 20 to the savings account Y, T2 sub- tracts 10 from the checking account X, Conclusion considering the withdrawal covered as There is great practical long as X+Y > 0, but accepting an value in understanding the properties overdraft with a penalty charge of 1 of database histories under weak iso- lation (that is, with concurrency

-3- control that does not automatically [TPC-C] TPC-C Benchmark Specification, available at guarantee serializable behavior). It http://www.tpc.org/ is especially important to understand what can and can’t happen when running under SI, in view of the wide commer- cial penetration of the Oracle DBMS, which implements SI. Several papers have identified sufficient conditions that can be checked for application programs to guarantee serializable be- havior for those applications [F99, BLL00]. We are in the process of at- tempting to develop a broad theory which covers the anomalies of Example 1.2 and 1.3, along with numerous oth- ers. We hope our theory will guide the application designer to adjust the programs without changing their func- tionality, so that serializability is guaranteed. References

[BBGMOO95] H. Berenson, P. Bernstein, J. Gray, J. Melton, E. O’Neil, and P. O’Neil. A Critique of ANSI SQL Isolation Levels. Proc. of the ACM SIGMOD International Conference on Management of Data, 1995. Pages 1-10.

[BHG87] P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. Addison Wesley, 1987. (This text is now out of print but can be downloaded from http://research.microsoft.com/pubs/ccontrol/default.htm)

[BLL00] A. Bernstein, P. Lewis and S. Lu. Semantic Conditions for Correctness at Different Isolation Levels. In Proceedings of IEEE International Conference on Data Engineering, 2000. Pages 57-66.

[F99] A. Fekete. Serializability and Snapshot Isolation. Proceedings of the Australian Database Conference, Auckland, New Zealand, January 1999. Pages 201-210.

[GR93] J. N. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann Publishers Inc., 1993.

[JAC95] K. Jacobs, with contributors: R. Bamford, G. Doherty, K. Haas, M. Holt, F. Putzolu, B. Quigley. Concurrency Control: Transaction Isolation and Serializability in SQL92 and Oracle7. Oracle White Paper, Part No. A33745, July, 1995.

[PAPA86] C. Papadimitriou. The Theory of Database Concurrency Control. Computer Science Press, 1986.

-4-