This paper describes four kinds of transaction isolation level, and by way of example illustrate different levels to solve what kind of reading phenomenon. The principle and different in a relational database isolation level implementation.
In a DBMS, a sequence of operations to ensure that the transaction can be executed or all not all execution (atomicity), the transition from one state to another state (consistency). Because the transaction to meet durability. Therefore, once the transaction has been committed, the data can be persisted down, and because the transaction is to meet the isolation, so that, when a plurality of transactions simultaneously process the same data, a plurality of transactions independently of each other directly, so during the concurrent operation of multiple transactions, if not properly controlled isolation level, it is possible to produce dirty reads, non-repeatable read, modify missing, such as read or phantom read phenomenon .
In the four ACID properties of database transactions, the isolation is a most relaxing one. Database may be utilized during operation of the data latch mechanism or multi-version concurrency control mechanism acquires a higher isolation level. However, with the improvement of the database isolation level, data concurrency will decline. So, how to make a good trade-off has become a critical issue between concurrency and isolation.
In software development, nearly every class of such problems will have a variety of best practices for our reference, many DBMS defines a number of different levels and concurrency "transaction isolation levels" to control the locks.
ANSI / ISO SQL standard defines four isolation levels, from high in the end were: serializable (the Serializable), repeatable read (Repeatable reads), Read Committed (Read committed), Uncommitted Read (Read uncommitted).
The following will in turn introduce the concept of the four transaction isolation levels, usage, and which problems (read phenomenon)
Uncommitted Read (Read uncommitted)
Uncommitted read (READ UNCOMMITTED) is the lowest level of isolation. We can know by name, in this transaction isolation level, a transaction can read data additional uncommitted transactions.
Uncommitted read the database lock situation (realization principle)
Services at the time of reading the data did not locking the data. When the transaction to modify the data only increases the data row-level shared lock .
phenomenon:
Transaction 1 reads a row record, transaction 2 can read these rows, update (because of the increased a transaction not any locks on the data)
When the transaction 2 updates the record, transaction 1 reads the record again, a modified version 2 can read the record of the transaction (because the transaction adds two shared read locks, the transaction can add a shared read lock read data), even if the amendment has not yet been submitted.
When Transaction 1 updates a row record, transaction 2 rows can not do this update until the end of the transaction 1. (Because the transaction adds a pair of data shared read locks, the transaction can not add two exclusive write locks to modify the data)
For example
| A transaction | Two affairs |
|---|---|
/* Query 1 */ SELECT age FROM users WHERE id = 1; /* will read 20 */ |
|
/* Query 2 */ UPDATE users SET age = 21 WHERE id = 1; /* No commit here */ |
|
/* Query 1 */ SELECT age FROM users WHERE id = 1; /* will read 21 */ |
|
ROLLBACK; /* lock-based DIRTY READ */ |
I still borrow at below On reading the phenomenon of the database in an article cited examples to illustrate the segregation between the uncommitted read isolation level in two transactions.
Transaction total query twice, in the course of two queries, the two pairs transaction data has been modified, did not submit (commit). But the affairs of a second inquiry found the two transactions modify the results. On reading phenomenon in the database, we introduced, a phenomenon we call dirty read.
So, read uncommitted will lead to dirty read
Read Committed (Read committed)
Read Committed (READ COMMITTED) can also be translated as read committed, by name can also be analyzed, in the course of a transaction modifies data, if the transaction is not committed, other transactions can not read the data.
Database lock submit the case to read (realization principle)
Plus transaction data currently read row-level locks a shared (read only when the lock) , upon reading the row, the row-level immediate release shared locks;
In an instant update transaction data (that is updated moment), it must first add row-level exclusive lock until the end of the transaction is not released .
phenomenon:
Reading a row of a transaction record of the whole process, a transaction can read from the two rows (rows because the transaction to increase a line-level shared lock case, the transaction may be increased two share the same data lock to read the data.).
1 reads a row instant transaction, the transaction can not modify the row 2 data, however, as long as a transaction data scanned and diverted, transaction 2 can be modified to the line data. (At the moment a transaction will increase the data read row-level shared locks, any other transaction can increase the data line exclusive lock. But as long as a transaction reading the row of data, row-level shared lock will be released once lock release, two transactions can increase exclusive lock on the data and modify data)
When a transaction updates a row 2 records, transaction records 1 can not do this line to read or update until the end of the transaction 2. (Transaction 2 updates the data in time, will increase an exclusive lock on the row data until the end of the transaction will release the lock, so 2 before the transaction did not submit the transaction 1 can not increase the data shared lock to read the data. Therefore, reading can be resolved to submit a dirty read phenomenon )
For example
| A transaction | Two affairs |
|---|---|
/* Query 1 */ SELECT * FROM users WHERE id = 1; |
|
/* Query 2 */ UPDATE users SET age = 21 WHERE id = 1; COMMIT; /* in multiversion concurrency control, or lock-based READ COMMITTED */ |
|
/* Query 1 */ SELECT * FROM users WHERE id = 1; COMMIT; /*lock-based REPEATABLE READ */ |
In the read committed isolation level, the two submitted before the transaction, a transaction can not read the data. Only after the transaction two commit a transaction to read data.
But we also see from the above example, the result of a transaction in a single transaction two reads are not consistent, so submit read read phenomenon can not solve the non-repeatable reads.
In short, the author read this isolation level ensures that any data read is submitted, avoiding the dirty read (dirty reads). But it does not guarantee transaction re-read when the same data can be read, because after reading each other transaction can modify data just read data.
Repeatable Read (Repeatable reads)
Repeatable read (REPEATABLE READS), since the author Read isolation level will have to read the phenomenon of non-repeatable reads. Therefore, a higher level than the read-committed isolation level can solve the problem of non-repeatable read. This is called repeatable read isolation levels.
Database locks the case of repeatable read
In an instant read transaction data (that is the moment to start reading), you must first add row-level shared locks until the end of the transaction is not released;
In an instant update transaction data (that is updated moment), you must first add row-level exclusive lock until the end of the transaction was released.
phenomenon
Reading a row of a transaction record of the whole process, a transaction can read from the two rows (rows because the transaction to increase a line-level shared lock case, the transaction may be increased two share the same data lock to read the data.).
Transaction 1 reads a row in the record of the whole process, the transaction can not modify the row 2 data (shared locks affairs 1 increase in the whole process will read data until the transaction commits will release the lock, so the whole process, any other transaction can increase the data line exclusive lock. so, repeatable read phenomenon can be solved read non-repeatable reads )
When Transaction 1 updates a row record, this transaction 2 rows do not read, update, until the end of the transaction 1. (Transaction 1 updates the data in time, will increase the bank's data row lock him know that end of the transaction will release the lock, so, before the transaction 2 is not submitted, a transaction can not increase the shared data locks to read data. Therefore, reading can be resolved to submit a dirty read phenomenon )
For example
| A transaction | Two affairs |
|---|---|
/* Query 1 */ SELECT * FROM users WHERE id = 1; COMMIT; |
|
/* Query 2 */ UPDATE users SET age = 21 WHERE id = 1; COMMIT; /* in multiversion concurrency control, or lock-based READ COMMITTED */ |
In the example above, only after submission of a transaction, the transaction can change the two rows of data. So, as long as during this time a transaction from start to finish, whether he read the line data many times, the result is the same.
From the above example we can conclude: Repeatable Read isolation level can solve the phenomenon of reading non-repeatable reads. But the Repeatable Read isolation level in this, there is another phenomenon could not read his resolve that phantom reads. See the examples below:
| A transaction | Two affairs |
|---|---|
/* Query 1 */ SELECT * FROM users WHERE age BETWEEN 10 AND 30; |
|
/* Query 2 */ INSERT INTO users VALUES ( 3, 'Bob', 27 ); COMMIT; |
|
/* Query 1 */ SELECT * FROM users WHERE age BETWEEN 10 AND 30; |
The above two transactions and the implementation of the phenomenon as follows:
1. The first query a transaction that age BETWEEN 10 AND 30;if this is the ten other records that match the conditions. At this time, he will give these ten qualifying record increase in share row-level locking. Any other transaction can not change these ten records.
2. The two transactions execute a sql statement, the content of the statement is to insert a row into the table. Because at this time there is no increase in business-to-table table-level locking , so that the operation can be performed smoothly.
3. execute a transaction again SELECT * FROM users WHERE age BETWEEN 10 AND 30;, the result is returned into a record eleven, compared with an increase of just one, this is where transactions increased just inserted two piece.
Therefore, the transaction twice a range of query results are not the same. This is what we mentioned phantom reads .
Serializable (the Serializable)
Serializable (the Serializable) is the highest isolation level of the isolation levels phantom read all the previously mentioned can not be solved in isolation level serializable can be solved.
We have said that the cause of phantom read is performed when a transaction does not increase the scope of inquiry lock range (range-locks: SELECT query to use a "WHERE" clause describes the scope lock), resulting in phantom reads.
Serializable database lock situation (realization principle)
Transaction data is read, you must first add its table-level shared locks until the end of the transaction is not released;
When a transaction update data, you must add its table-level exclusive lock until the end of the transaction was released.
phenomenon
A transaction record 1 in the table is being read, the transaction 2 in Table A can be read, but can not do updates to the A table, add, delete, 1 until the transaction is completed. (Because the transaction adds a pair of tables table-level shared lock, other transactions can only increase the shared lock to read the data, you can not do anything else)
A transaction record 1 in the table is being updated, the transaction can not read any record 2 A table, A table less likely to do the update, add, delete, 1 until the transaction is completed. (Transaction adds a pair of tables table-level exclusive lock, other transactions can not increase the shared table lock or exclusive lock, it can not carry out any operation)
Although the sequence of solving the dirty read, non-repeatable read, phantom read, etc. read on. But the sequence of the transaction will have the following effects:
1. Can not read record has been modified by other transactions but not submitted.
2. Prior to the completion of the current transaction, other transactions can not modify the current record transaction has read.
3. Before the completion of the current transaction, other firms insert a new record, which is the index key value in the index key range is not currently any statement in the read transaction.
Four kinds of transaction isolation level from getting high degree of isolation, but also getting lower and lower on concurrency. The reason why there are so few isolation level, is to facilitate the developers need to select the most appropriate isolation level based on business in the development process.