Transaction Isolation Levels and Object Oriented Data Structures
Michael Hollins Bullant Technology
Email: [email protected] Abstract An ACID Transaction Processing System (TP System) must support complete isolation of a running transaction from other concurrently running transactions. Unfortunately, universal support for such complete isolation can have serious affects on the overall transactional throughput of a TP system. It is possible and desirable to be able to reduce the isolation guarantees for a transaction in return for improved performance. Such an approach is very common in commercial relational database systems. Object oriented persistent systems present unique difficulties for providing reduced isolation guarantees. Unlike in relational systems where the relation is the only means for collecting multiple data items, persistent systems allow the application programmer to build their own collection data structures. Common examples include linked lists, vectors, hash tables, binary trees etc. This paper presents the commencement of a research effort into analysing the ability of such data structures to be sensibly manipulated at weaker isolation levels. Specifically the paper briefly examines two isolation levels, serializable and snapshot isolation and considers their applicability to the manipulation of a linked list data structure. 1 Introduction
The well known ACID transaction properties are the industry standard means for describing a well-behaved transaction processing system. ACID gets its name from the initials of the four required properties of ACID transactions (Atomic, Consistent, Isolated and Durable): Atomic The changes made by a transaction are atomic. Either they all occur or none of them occur.
Consistent A transaction is a correct transformation of the data. That is, the actions of the transaction must not violate any internal or user-defined constraints.
Isolated It appears to a transaction that it is running alone, without interference from other transactions.
Durable Once a transaction commits, its changes to data survive failures - a ’fact is always a fact’. This paper focuses on the Isolation property and the ability to weaken the isolation guarantee in return for performance improvements without compromising correctness. Specifically the paper examines two isolation levels, serializable and snapshot isolation and considers their applicability to the manipulation of a linked list data structure. In the interests of brevity only lock-based implementations are considered. The intent of this paper is merely to give a flavour for the area. Our aim for the research in general is to consider many data structures, a number of isolation levels, both lock-based and non lock-based systems and to perform measurements on real systems. 2 Isolation
An ACID system must support complete Isolation of a running transaction from other concurrently running transactions. This isolation is normally expressed in terms of the serializability of the transactions. That is, the results of running transactions concurrently must be equal to a result gained by running those transactions one at a time in a serial fashion (in any order). ANSI SQL-92 [ANSI 1992] defines four distinct levels of isolation. The levels are expressed with respect to particular phenomena that each level allows or prevents. More recently, other levels of isolation have been identified by distinguishing between phenomena and anomalies not covered by the ANSI specification [BERENSON et al 1995][ADYA 1999]. 2.1 Serializability The most common means of implementing serializability is for a transaction to acquire a read lock the first time it reads an object and a write lock the first time that it writes to an object. All locks are held until the transaction completes (either commits or aborts). A read lock held by transaction T1 on object O blocks any other transaction from acquiring a write lock on O until T1 completes. A write lock held by transaction T1 on object O blocks any other transaction from acquiring any type of lock on O until T1 completes. 2.2 Multi-Versioned Systems and Snapshot Isolation A multi-versioned database system retains multiple versions of each persistent object. The system maintains the current value of each object as well previous values that it has held. It is possible for a transaction to read previous values of objects if required. Snapshot Isolation is an isolation level that makes use of object multi-versioning to remove the need for transactions to acquire read locks. To see how this works consider that an important property of isolated transactions is that if a transaction T reads the value of an object O more than once, it should retrieve the same value each time (the read is repeatable). Updates to an O being made by other concurrently running transactions must not be visible to T once T has read O the first time. In the serializable system just described this is achieved by acquiring a read lock on the object before the first read. This ensures that the value of the object cannot be altered for the entire execution of the transaction. In a multi-versioned system repeatable reads can be achieved without using read locks by providing transactions with snapshot reads as defined below:
Snapshot Reads All reads by a transaction retrieve the value of objects as at the instant in time that the transaction commenced executing (except reads of objects that the transaction has itself modified).
Thus snapshot isolation provides repeatable reads without using read locks. The motivation for this is that it increases the potential concurrency in the system by avoiding the blocking of transactions due to read-write conflicts with other transactions. Only write-write conflicts exist under snapshot isolation. The following sections consider this motivation with respect to a linked list data structure. 2.3 Serializable vs Snapshot Isolation for Linked Lists For this analysis a simple ordered linked list is used as shown in Figure 1. New elements are inserted into the list in ascending numerical order. head 10 20 30 40
)LJXUH$Q2UGHUHG/LQNHG/LVW
Consider a transaction T1 that inserts the number 35 into the list. Figure 2 shows the read and write sets of T1. A serializable system will acquire write locks for all of the objects in T1’s write set and read locks for all the objects in T1’s read set. The snapshot isolation system will only acquire the write locks.
head 10 20 30 40
35 T1 Reads
T1 Writes
)LJXUH5HDG:ULWH6HWVRI7
2.3.1 Snapshot Isolation Improves Concurrency Consider the list shown in Figure 1 and the two transactions T2 & T3 shown below.
7Ã LQVHUWÃÃ 7Ã LQVHUWÃÃ
Figure 3 shows the read and writes sets of T2 and T3. In order to insert the values in the appropriate place, T2 needs to scan the list up to node 20, while T3 needs to scan up to node 40. The insert operation of T2 needs to modify node 10 and the newly created node
15. Likewise, T3 needs to modify node 30 and the newly created node 35. The read set of T3 intersects with the write set of T2. This means that at the serializable isolation level one or other of the transactions will be delayed awaiting the release of locks held by the other transaction. Snapshot isolation, on the other hand, would allow T2 and T3 to execute concurrently while still delivering serializable results. At the snapshot isolation level, there is no conflict between the two transactions. Only write-write conflicts exist in snapshot isolation. Read-write conflicts, and consequently the need for read locks, are removed by providing transactions with snapshot reads. For example, if T2 is in the middle of updating node 10, then under serializable isolation T3 would have to wait till T2 completes in order to ensure that it sees a consistent view of node 10. Under snapshot isolation T3 is provided with a consistent view of node 10 by providing it with the state of the object before T2 commenced modifying the node.
head 10 20 30 40
15 35 T2 Reads
T2 Writes
T3 Reads
T3 Writes
)LJXUH5HDG:ULWH6HWVRI77
2.3.2 Write-write conflicts (forced aborts under snapshot isolation) What if a genuine write-write conflict exists when using snapshot isolation? For example, consider the transactions T4 and T5. Running T4 and T5 concurrently without some form of synchronisation will result in erroneous results. 7Ã LQVHUWÃÃ 7Ã LQVHUWÃÃ
The read and write sets for T4 and T5 are shown in Figure 4. Under snapshot isolation, if say T4 acquires the write lock on node 30 before T5 then T5 will block waiting for the lock to be released. If T4 continues on and commits then the system must abort the execution of T5 due to the fact that node 30 has been updated by another transaction since T5 started. This is to avoid an anomaly known as lost update (see BERENSON et al [1995]). Basically, once the snapshot isolation system detects a write-write conflict it must abort one or other of the transactions. This is due to the fact that it has no knowledge of the reads made by each of the transactions and must err on the side of caution and presume that allowing any such modification of the object could potentially result in a lost update.
In contrast, the serializable system’s ability to detect the conflict early enables it to block T5 before it has a chance to get itself into an un-committable state. When the situation is safe (T4 has committed and released its locks) T5 may be resumed and completed successfully.
head 10 20 30 40 35
33 T4 Writes T4 and T5 Reads T5 Writes
)LJXUH5HDG:ULWH6HWVRI77
It is our belief that such conflicts are less common than the the read-write conflicts experienced at the serializable isolation level. If this is true, snapshot isolation should provide better performance than the serializable isolation level for liked lists and similar data structures. One of the goals of this research is to test such beliefs empirically by measuring real systems running real applications.
2.3.3 Skewed Writes - The real price of Snapshot Isolation Snapshot isolation relies on the observation that as long as transactions are provided with consistent (snapshot) reads then most conflicting transactions will show up as write-write conflicts. The only exception to this observation is the Write Skew anomaly (see BERENSON et al [1995]). Skewed writes are conflicts in which the write sets of the two conflicting transactions do not intersect. Skewed writes can only be detected by observing the reads of a transaction. Snapshot isolation ignores reads and is thereby prone to skewed writes. For example, consider the linked list shown in Figure 5 and the transactions T6 and T7 below.
head 10 20 30
)LJXUH2UGHUHG/LQNHG/LVW
7Ã LQVHUWÃÃ 7Ã GHOHWHÃÃ
Figure 6 and Figure 7 show the read and write sets of T6 and T7 respectively. Notice that the write set of T6 does not intersect with the write set of T7. The transactions exhibit the Write Skew anomaly. Snapshot Isolation will not detect these transactions as conflicting. If T6 and T7 are allowed to run concurrently the results of T6 will be lost. In contrast, the write set of T6 does intersect with the read set of T7 (and vice versa). Thus, if the transactions are run at full serializability then the conflict will be detected.
head 10 20 30
Reads 25 Writes
)LJXUH5HDGDQG:ULWHVHWVRI7
head 10 20 30 Reads
Writes
)LJXUH5HDGDQG:ULWHVHWVRI7
2.3.3.1 Avoiding Write Skew
In order to avoid write skew a number of approaches can be taken:
• Use the serializable isolation level instead. Here the preference is for ease of programming over performance.
• Re-implement the data structure such that it is not prone to write skew. For example, a suitably implemented doubly linked list is not prone to write skew. This is shown in Figure 8 and Figure 9. Both operations update node 30 allowing the conflict to be detected as a write-write conflict.
• Provide the ability for programs to manually acquire read locks when specifically needed to avoid write skews. In the case of the linked list example above, write skew can be avoided by enhancing the remove operation to grab an explicit read lock on the node being removed (node 20). This is preferable (in terms of performance) to using the serializable isolation level which would conservatively
(pessimistically) place read locks on all of the nodes visited by the remove operation.
head 10 20 30
Reads 25 Writes
)LJXUH:ULWHDQG5HDGVHWVRIGRXEO\OLQNHGOLVWLQVHUW RSHUDWLRQ
head 10 20 30
Reads
Writes
)LJXUH :ULWHDQG5HDGVHWVRIGRXEO\OLQNHGOLVWUHPRYH RSHUDWLRQ
3 Conclusion and Future Work
This paper briefly considered the suitability of two isolation levels, serializable and snapshot isolation for the manipulation of a linked list data structure. Neither isolation level delivers higher performance in all cases. The performance of each level depends very much on the particular access patterns of the transactions in question. Also the exposure of underlying mechanisms to allow programmers to implement their own hybrid isolation levels will potentially provide for performance that is better than either of the standard isolation levels. Analysis such as that presented here leads to the belief that a high performance object- oriented transaction processing system (TP System) will be achieved by a combination of factors including
• An efficient implementation of the underlying TP System,
• The provision of collection libraries optimised for the specific TP System, and
• The ability to allow application programmers to optionally adopt some of the responsibility for maintaining isolation between transactions in return for higher transactional throughput. The future goals for this research include the following
• Examine other common data structures, other isolation levels and both lock-based and non lock-based systems,
• Perform measurements on real systems running real applications,
• Design and implement interfaces to expose underlying primitives in order to allow application programmers to develop their own hybrid isolation levels, and to
• Develop data structure libraries optimised for transactional use. 4 Bibliography
ANSI 1992 - ANSI X3.135-1992 ADYA, A. 1999 Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions. PhD thesis, MIT, 1999. BERENSON, H., BERNSTEIN, P., GRAY, J., MELTON, J., O’NEIL, E., O’NEIL, P.. 1995. A Critique of ANSI SQL Isolation Levels. Proceedinsg ACM SIGMOD 95, pp 1- 10, June 1995.