Isolation (Database Systems)
Isolation (Database Systems)
Concurrency control
Concurrency control comprises the underlying mechanisms in a DBMS which handles isolation and guarantees
related correctness. It is heavily utilized by the database and storage engines (see above) both to guarantee the
correct execution of concurrent transactions, and (different mechanisms) the correctness of other DBMS processes.
The transaction-related mechanisms typically constrain the database data access operations' timing (transaction
schedules) to certain orders characterized as the serializability and recoverability schedule properties. Constraining
database access operation execution typically means reduced performance (rates of execution), and thus concurrency
control mechanisms are typically designed to provide the best performance possible under the constraints. Often,
when possible without harming correctness, the serializability property is compromised for better performance.
However, recoverability cannot be compromised, since such typically results in a quick database integrity violation.
Two-phase locking is the most common transaction concurrency control method in DBMSs, used to provide both
serializability and recoverability for correctness. In order to access a database object a transaction first needs to
acquire a lock for this object. Depending on the access operation type (e.g., reading or writing an object) and on the
lock type, acquiring the lock may be blocked and postponed, if another transaction is holding a lock for that object.
Isolation levels
Of the four ACID properties in a DBMS (Database Management System), the isolation property is the one most
often relaxed. When attempting to maintain the highest level of isolation, a DBMS usually acquires locks on data or
implements multiversion concurrency control, which may result in a loss of concurrency. This requires adding logic
for the application to function correctly.
Most DBMSs offer a number of transaction isolation levels, which control the degree of locking that occurs when
selecting data. For many database applications, the majority of database transactions can be constructed to avoid
requiring high isolation levels (e.g. SERIALIZABLE level), thus reducing the locking overhead for the system. The
programmer must carefully analyze database access code to ensure that any relaxation of isolation does not cause
software bugs that are difficult to find. Conversely, if higher isolation levels are used, the possibility of deadlock is
increased, which also requires careful analysis and programming techniques to avoid.
The isolation levels defined by the ANSI/ISO SQL standard are listed as follows.
Serializable
This is the highest isolation level.
With a lock-based concurrency control DBMS implementation, serializability requires read and write locks (acquired
on selected data) to be released at the end of the transaction. Also range-locks must be acquired when a SELECT
query uses a ranged WHERE clause, especially to avoid the phantom reads phenomenon (see below).
When using non-lock based concurrency control, no locks are acquired; however, if the system detects a write
collision among several concurrent transactions, only one of them is allowed to commit. See snapshot isolation for
more details on this topic.
Isolation (database systems) 2
Repeatable reads
In this isolation level, a lock-based concurrency control DBMS implementation keeps read and write locks (acquired
on selected data) until the end of the transaction. However, range-locks are not managed, so the phantom reads
phenomenon can occur (see below).
Read committed
In this isolation level, a lock-based concurrency control DBMS implementation keeps write locks (acquired on
selected data) until the end of the transaction, but read locks are released as soon as the SELECT operation is
performed (so the non-repeatable reads phenomenon can occur in this isolation level, as discussed below). As in the
previous level, range-locks are not managed.
Putting it in simpler words, read committed is an isolation level that guarantees that any data read is committed at the
moment it is read. It simply restricts the reader from seeing any intermediate, uncommitted, 'dirty' read. It makes no
promise whatsoever that if the transaction re-issues the read, it will find the same data; data is free to change after it
is read.
Read uncommitted
This is the lowest isolation level. In this level, dirty reads are allowed (see below), so one transaction may see
not-yet-committed changes made by other transactions.
Since each isolation level is stronger than those below, in that no higher isolation level allows an action forbidden by
a lower one, the standard permits a DBMS to run a transaction at an isolation level stronger than that requested (e.g.,
a "Read committed" transaction may actually be performed at a "Repeatable read" isolation level).
Read phenomena
The ANSI/ISO standard SQL 92 refers to three different read phenomena when Transaction 1 reads data that
Transaction 2 might have changed.
In the following examples, two transactions take place. In the first, Query 1 is performed. Then, in the second
transaction, Query 2 is performed and committed. Finally, in the first transaction, Query 1 is performed again.
The queries use the following data table:
users
id name age
1 Joe 20
2 Jill 25
Transaction 1 Transaction 2
<font size="9.40">
/* Query 1 */
SELECT age FROM users WHERE id = 1;
/* will read 20 */
</font>
<font size="9.40">
/* Query 2 */
UPDATE users SET age = 21 WHERE id = 1;
/* No commit here */
</font>
<font size="9.40">
/* Query 1 */
SELECT age FROM users WHERE id = 1;
/* will read 21 */
</font>
<font size="9.40">
ROLLBACK; /* lock-based DIRTY READ */
</font>
But in this case no row exists that has an id of 1 and an age of 21.
Isolation (database systems) 4
Non-repeatable reads
A non-repeatable read occurs, when during the course of a transaction, a row is retrieved twice and the values within
the row differ between reads.
Non-repeatable reads phenomenon may occur in a lock-based concurrency control method when read locks are not
acquired when performing a SELECT, or when the acquired locks on affected rows are released as soon as the
SELECT operation is performed. Under the multiversion concurrency control method, non-repeatable reads may
occur when the requirement that a transaction affected by a commit conflict must roll back is relaxed.
Transaction 1 Transaction 2
<font size="9.40">
/* Query 1 */
SELECT * FROM users WHERE id = 1;
</font>
<font size="9.40">
/* Query 2 */
UPDATE users SET age = 21 WHERE id = 1;
COMMIT; /* in multiversion concurrency
control, or lock-based READ COMMITTED */
</font>
<font size="9.40">
/* Query 1 */
SELECT * FROM users WHERE id = 1;
COMMIT; /* lock-based REPEATABLE READ */
</font>
In this example, Transaction 2 commits successfully, which means that its changes to the row with id 1 should
become visible. However, Transaction 1 has already seen a different value for age in that row. At the
SERIALIZABLE and REPEATABLE READ isolation levels, the DBMS must return the old value for the second
SELECT. At READ COMMITTED and READ UNCOMMITTED, the DBMS may return the updated value; this is
a non-repeatable read.
There are two basic strategies used to prevent non-repeatable reads. The first is to delay the execution of Transaction
2 until Transaction 1 has committed or rolled back. This method is used when locking is used, and produces the
serial schedule T1, T2. A serial schedule exhibits repeatable reads behaviour.
In the other strategy, as used in multiversion concurrency control, Transaction 2 is permitted to commit first, which
provides for better concurrency. However, Transaction 1, which commenced prior to Transaction 2, must continue to
operate on a past version of the database — a snapshot of the moment it was started. When Transaction 1 eventually
tries to commit, the DBMS checks if the result of committing Transaction 1 would be equivalent to the schedule T1,
T2. If it is, then Transaction 1 can proceed. If it cannot be seen to be equivalent, however, Transaction 1 must roll
back with a serialization failure.
Using a lock-based concurrency control method, at the REPEATABLE READ isolation mode, the row with ID = 1
would be locked, thus blocking Query 2 until the first transaction was committed or rolled back. In READ
COMMITTED mode, the second time Query 1 was executed, the age would have changed.
Under multiversion concurrency control, at the SERIALIZABLE isolation level, both SELECT queries see a
snapshot of the database taken at the start of Transaction 1. Therefore, they return the same data. However, if
Transaction 1 then attempted to UPDATE that row as well, a serialization failure would occur and Transaction 1
would be forced to roll back.
At the READ COMMITTED isolation level, each query sees a snapshot of the database taken at the start of each
query. Therefore, they each see different data for the updated row. No serialization failure is possible in this mode
Isolation (database systems) 5
(because no promise of serializability is made), and Transaction 1 will not have to be retried.
Phantom reads
A phantom read occurs when, in the course of a transaction, two identical queries are executed, and the collection of
rows returned by the second query is different from the first.
This can occur when range locks are not acquired on performing a SELECT ... WHERE operation. The phantom
reads anomaly is a special case of Non-repeatable reads when Transaction 1 repeats a ranged SELECT ... WHERE
query and, between both operations, Transaction 2 creates (i.e. INSERT) new rows (in the target table) which fulfill
that WHERE clause.
Transaction 1 Transaction 2
<font size="9.50">
/* Query 1 */
SELECT * FROM users
WHERE age BETWEEN 10 AND 30;
</font>
<font size="9.50">
/* Query 2 */
INSERT INTO users VALUES ( 3, 'Bob', 27 );
COMMIT;
</font>
<font size="9.50">
/* Query 1 */
SELECT * FROM users
WHERE age BETWEEN 10 AND 30;
</font>
Note that Transaction 1 executed the same query twice. If the highest level of isolation were maintained, the same set
of rows should be returned both times, and indeed that is what is mandated to occur in a database operating at the
SQL SERIALIZABLE isolation level. However, at the lesser isolation levels, a different set of rows may be returned
the second time.
In the SERIALIZABLE isolation mode, Query 1 would result in all records with age in the range 10 to 30 being
locked, thus Query 2 would block until the first transaction was committed. In REPEATABLE READ mode, the
range would not be locked, allowing the record to be inserted and the second execution of Query 1 to include the
new row in its results.
Serializable - - -
Anomaly Serializable is not the same as Serializable. That is, it is necessary, but not sufficient that a Serializable
schedule should be free of all three phenomena types. See [1] below.
"may occur" means that the isolation level suffers that phenomenon, while "-" means that it does not suffer it.
Read Uncommitted S S S
Read Committed C S S
Repeatable Read C C S
Serializable C C C
References
External links
• Oracle® Database Concepts (http://docs.oracle.com/cd/B12037_01/server.101/b10743/toc.htm), chapter 13
Data Concurrency and Consistency, Preventable Phenomena and Transaction Isolation Levels (http://docs.
oracle.com/cd/B12037_01/server.101/b10743/consist.htm#sthref1919)
• Oracle® Database SQL Reference (http://docs.oracle.com/cd/B19306_01/server.102/b14200/toc.htm),
chapter 19 SQL Statements: SAVEPOINT to UPDATE (http://docs.oracle.com/cd/B19306_01/server.102/
b14200/statements_10.htm#i2068385), SET TRANSACTION (http://docs.oracle.com/cd/B19306_01/
server.102/b14200/statements_10005.htm#i2067247)
• in JDBC: Connection constant fields (http://docs.oracle.com/javase/7/docs/api/java/sql/Connection.
html#field_summary), Connection.getTransactionIsolation() (http://docs.oracle.com/javase/7/docs/api/java/
sql/Connection.html#getTransactionIsolation()), Connection.setTransactionIsolation(int) (http://docs.oracle.
com/javase/7/docs/api/java/sql/Connection.html#setTransactionIsolation(int))
• in Spring Framework: @Transactional (http://static.springsource.org/spring/docs/current/javadoc-api/org/
springframework/transaction/annotation/Transactional.html), Isolation (http://static.springsource.org/spring/
docs/current/javadoc-api/org/springframework/transaction/annotation/Isolation.html)
Article Sources and Contributors 7
License
Creative Commons Attribution-Share Alike 3.0
//creativecommons.org/licenses/by-sa/3.0/