Table of contents
Spring transaction isolation level
Why transaction isolation? Without transaction isolation, when multiple transactions are concurrent, problems such as lost updates, dirty reads, non-repeatable reads, and phantom reads will occur.
1. There are no problems caused by transaction isolation
1. Update lost
When two or more transactions update the same row of records, update loss occurs. It can be divided into rollback coverage and commit coverage.
For example: transaction T1 queries data, transaction T2 queries data, transaction T1 modifies the data and submits, and transaction T2 modifies the data. At this time, transaction T2 commits or rolls back, which will cause the data modified by transaction T1 to be overwritten.
2. Dirty reading
Dirty reading is also called invalid data reading. One transaction reads data that another transaction has not yet committed.
For example, transaction T1 modifies a row of data but has not yet submitted it. At this time, transaction T2 reads the data modified by transaction T1. Then transaction T1 rollbacks for some reason, so the data read by transaction T2 is dirty.
3. Non-repeatable reading
It means that multiple queries on the same row of data within the same transaction return different results.
For example, transaction T1 queries a certain row of data for the first time, and then transaction T2 modifies a certain field of the row of data and submits the data. When transaction T1 queries the row of data for the second time, it obtains the modified results of transaction T2.
The difference between non-repeatable read and dirty read is that dirty read reads uncommitted data, while non-repeatable read reads committed data. Of course, non-repeatable reading is not a problem in some cases. Sometimes we just want to query the latest status of the data in the same transaction.
4. Phantom reading
Phantom reading is also called virtual reading. Multiple queries of the same SQL statement in the same transaction will result in different amounts of data (number of items).
For example, transaction T1 modifies a data item in all rows in a table from "1" to "2". At this time, transaction T2 inserts a row of data items into the table, and the data item's The value is still "1" and submitted to the database. If the user who operates transaction T1 looks at the data that was just modified, he will find that there is still one row that has not been modified. In fact, this row was added from transaction T2. It is like an hallucination. This is a phantom read.
2. Use the isolation level of the transaction to solve the problem
Usage of isolation level
The @Transactional annotation sets the transaction isolation level through the isolation attribute
@Transactional(isolation=Isolation.DEFAULT)
public void methodA(){
// 业务逻辑
// 操作数据库
}
3. The isolation attribute has the following five values:
1、DEFAULT
This is the default value, which means it is consistent with the isolation level set by the connected database.
2、READ_UNCOMMITTED
Read uncommitted (dirty reads, non-repeatable reads, phantom reads will occur) and are basically not used
On the premise of operating on the same row of data, a read transaction allows other read transactions and write transactions. An uncommitted write transaction prohibits other write transactions but allows other read transactions. This isolation level can prevent update loss, but it cannot prevent dirty reads, non-repeatable reads, and phantom reads. This isolation level can be achieved through an "exclusive write lock".
3、READ_COMMITTED
Read committed (non-repeatable reads and phantom reads will occur)
Based on the premise of operating the same row of data, read transactions allow other read transactions and write transactions, and uncommitted write transactions prohibit other read transactions and write transactions. This isolation level can prevent lost updates and dirty reads, but it cannot prevent non-repeatable reads and phantom reads. This isolation level can be achieved through "transient shared read locks" and "exclusive write locks".
4、REPEATABLE_READ
Repeatable reading (phantom reading may occur)
Based on the premise of operating the same row of data, a read transaction prohibits other write transactions (but allows other read transactions), and an uncommitted write transaction prohibits other read transactions and write transactions. This isolation level can prevent lost updates, dirty reads, and non-repeatable reads, but it cannot prevent phantom reads. This isolation level can be achieved through "shared read locks" and "exclusive write locks".
5、SERIALIZABLE
Serializable
Provide strict transaction isolation. It requires transactions to be executed serially, and transactions can only be executed one after another and cannot be executed concurrently. This isolation level prevents lost updates, dirty reads, non-repeatable reads, and phantom reads. If transaction serialization cannot be achieved only through "row-level locking", other mechanisms must be used to ensure that newly inserted data will not be accessed by the transaction that just executed the query operation. This transaction isolation level is inefficient and consumes database performance, so it is generally not used.
4. Extension:
1. Default transaction isolation level of common databases
Oracle, the default isolation level of Sql Server is READ_COMMITTED,
The default isolation level of Mysql is REPEATABLE_READ.
2. The isolation level setting is only effective for the current connection.
For using the Mysql command window, a window is equivalent to a connection, and the isolation level set by the current window is only effective for transactions in the current window; for JDBC operating databases, a Connection object is equivalent to a link, and for the Connection object The isolation level set is only valid for Connection objects and has nothing to do with other linked Connection objects.
3. Setting the isolation level of the database must be done before starting the transaction.
Transaction in mybatis:
It implements transaction submission and rollback through the commit method and rollback method of the sqlSession object.
4. Common SQL settings for isolation levels
View the current transaction isolation level: select @@transaction_isolation;
Set the transaction isolation level of the current session: set session transaction isolation level XXX (isolation level);
Set the current global transaction isolation level: set global transaction isolation level XXX (isolation level);