Database isolation level
Purpose: To ensure the correctness of concurrent data read by transactions
Database transaction isolation level
(1) Read uncommitted (read uncommitted data): Allows a transaction to read changed data that has not been committed by other transactions, and there will be dirty reads, non-repeatable reads, and virtual reads.
(2) Read committed (read committed data): Only transactions are allowed to read changed data that has been committed by other transactions, which can avoid dirty reads, and there will still be non-repeatable reads and virtual reads
(3) Repeatable read: Ensure that a transaction can read the same value from a field multiple times. During the duration of this transaction, other transactions are prohibited from updating this field, which can avoid dirty reads and non-repeatable reads. There will be false readings.
(4) Serializable: Ensure that transactions can read the same rows from a table, and prohibit other transactions from performing insert, update, and delete operations on the table during the duration of the transaction, avoiding all concurrency problems, but low performance .
MySQL supports four transaction isolation levels, of which REPEATABLE READ is the default transaction isolation level.
Setting description: The higher the isolation level, the better the data integrity and consistency can be guaranteed, but the greater the impact on concurrency. For most applications, the isolation level of the database system is set to ReadCommitted. It can avoid dirty reads and has better concurrent performance. For concurrency problems such as non-repeatable read, virtual read, and the second type of lost update, use pessimistic locking or optimistic locking.
Pessimistic locking and optimistic locking
Pessimistic lock: I am afraid that others will modify it every time I get the data, so I will lock it first, and block it when other transactions want to access the data. Generally used in table locks, row locks, read locks and write locks, lock before the operation.
Optimistic locking: Every time you take data, you think that others will not modify it or lock it, but when updating, it will first judge whether others have updated the data during this period, and you can use mechanisms such as version numbers.
Applicable to: In the case of many reads and few writes, the throughput can be improved.
DB2 transaction isolation level:
(1) Uncommitted read (UR - uncommitted read)
When reading data, the IN table lock is added to the table, but the data row is not locked. When modifying data, add X locks and corresponding table-level locks to the data (modification operations are the same as CS processing).
Concurrency: Lost updates, dirty reads, non-repeatable reads, and dummy reads are all possible
(2) Cursor stability (CS - cursor stability) default level : only lock the currently processed record
Locks the current row positioned by the cursor. NS lock is added to read, X lock is added to modification, and U lock is added to query with modification. The lock lasts until the next entry is read or the transaction ends.
Concurrency: Lost updates and dirty reads do not occur; however, non-repeatable reads and dummy reads are possible.
(3) Read statility (RS - read stability)
Just lock the rows actually retrieved and modified by the transaction (add NS for reading, X for modification, and U for modification intention)
Concurrency: Lost updates, dirty reads, and non-repeatable reads do not occur; however, false reads may occur.
（4）Repeatable read（RR）
Locks all rows of select and locks all scanned rows
Concurrency: Lost updates, dirty reads, non-repeatable reads, and dummy reads do not occur