ACID properties of database transactions, database concurrency issues and four isolation levels

ACID properties of database transactions, database concurrency issues and four isolation levels

Database transaction

A database transaction is a set of logical operation units that transform data from one state to another

A set of logical operation units; one or more DML operations

Transaction processing principle

Ensure that all transactions are executed as a unit of work, even if there is a failure, this way of execution cannot be changed.
When a transaction performs multiple operations, either all transactions are committed and then stored permanently; or all modifications are discarded, and the entire transaction is rolled back to the original state

Once the data is submitted, it cannot be rolled back

Those actions will result in automatic submission

Once the DDL operation is executed, it will automatically submit the
DML. By default, once executed, it will be automatically submitted.
You can cancel the DML auto-commit by setting autocommit = false.
By default, the data will be automatically submitted when the connection is closed.

ACID attributes

The transaction must satisfy four attributes, namely, Atomicity, Consistency, Isolation, and Durability, that is, the four attributes of ACID.

Atomicity

A transaction is an indivisible whole. In order to ensure the overall goal of the transaction, the transaction must be atomic, that is, when the data is modified, either all of them are executed, or none of them are executed. That is, the transaction is not allowed to be partially completed, avoiding errors caused by only performing a part of these operations.

consistency

Before and after a transaction is executed, the database data must be consistent. The consistency state of the database should meet the constraints specified by the mode lock, so after the transaction is completely executed, the database is still in a consistent state.

For example: bank transfer, the sum of the two accounts before and after the transfer should remain unchanged.

Isolation

Modifications made by concurrent firms must be isolated from modifications made by any other concurrent firms. The state of the data when the transaction views the database is either the state before another concurrent transaction modifies it, or the state after another transaction modifies it. The transaction does not view the data in the intermediate state.

For example: for any pair of transactions T1 and T2, for T1, T2 either ends before T1 starts, or starts execution after T1 finishes.

Endurance

Also known as permanent. After the transaction is completed, the DBMS (Database Management System) guarantees that the modification of the data in the database is permanent. When the system or medium fails, the modification is also permanently maintained. Durability is generally guaranteed through database backup and recovery.

• Note Strictly speaking, database transaction attributes are guaranteed by the database management system. During the operation of the entire application, the application does not need to consider the ACID implementation of the database.

Under normal circumstances, the transaction is terminated by executing a COMMIT (commit) or ROLLBACK (rollback) statement. When the COMMIT statement is executed, all changes made to the database since the start of the transaction become permanent, that is, are written to disk, and when the ROLLBACK statement is executed, all changes made to the database since the start of the transaction will be Undo, and the contents of the database are returned to the state they were in before the transaction started. In any case, when the transaction is completed, it can be guaranteed to return to a consistent state.

Database concurrency issues

If there is no lock and multiple users access a database at the same time, problems may occur when their transactions use the same data at the same time. Data inconsistencies caused by concurrent operations include: lost data updates, read "dirty" data (dirty reads), and non-repeatable reads.

Update lost

• Both transactions update a row of data at the same time, and the update of the data by one transaction overwrites the update of the data by the other transaction. This is because the system does not perform any lock operations, so concurrency is not isolated.

Dirty read

• A transaction reads the uncommitted data operation result of another transaction. This is quite dangerous, because all operations are likely to be rolled back.

Non-repeatable

• Non-repeatable Reads: A transaction reads the same row of data twice, but got different results.

Including the following situations:

• Dummy read: After transaction T1 reads a certain data, transaction T2 modifies it, and when transaction T1 reads the data again, it gets a different value from the previous time.
• Phantom reading: The transaction performs two queries during the operation. The result of the second query contains data that did not appear in the first query or lacks data that appeared in the first query. This is caused by another transaction inserting data during the two queries.

Four isolation levels of database transactions

There are four isolation levels for database transactions, from low to high, they are Read uncommitted, Read committed, Repeatable read, and Serializable. These four levels can solve the problems of dirty read, non-repeatable read, and phantom read one by one.
Different isolation levels handle transactions differently.

• Read Uncommitted: Only handle lost updates. If a transaction has started to write data, other transactions are not allowed to write at the same time, but other transactions are allowed to read this row of data. It can be achieved by "exclusive write lock".
• Read committed data (Read Committed): deal with lost updates and dirty reads. The transaction that reads the data allows other transactions to continue to access the changed row data, but the uncommitted write transaction will prohibit other transactions from accessing the changed row. It can be realized by "instant shared read lock" and "exclusive write lock".
• Repeatable Read (Repeatable Read): deal with lost update, dirty read and non-repeatable read. A transaction that reads data will prohibit a write transaction, but a read transaction is allowed, and a write transaction prohibits any other transactions. It can be realized by "shared read lock" and "exclusive write lock".
• Serialization (Serializable): Provides strict transaction isolation. Requires loss of serialization execution, transactions can only be executed one after another, and cannot be executed concurrently. Transaction serialization cannot be achieved only through "row-level locks", and other mechanisms must be used to ensure that newly inserted data will not be accessed by the transaction that just performed the query operation.

The higher the isolation level, the more the integrity and unity of the data can be guaranteed, but the greater the impact on concurrent performance. For most applications, you can first consider setting the isolation level of the database system to Read Committed. It can avoid dirty reads and has good concurrency performance. Although it can cause concurrency problems such as non-repeatable reads, phantom reads, and the second type of lost update, the application can use pessimistic locks or optimistic locks to control the individual occasions where such problems may occur.

• Oracle supports two transaction isolation levels: READ COMMITED, SERIALIZABLE. Oracle's default transaction isolation level is: READ COMMITED
• Mysql supports 4 transaction isolation levels. The default transaction isolation level of Mysql is: REPEATABLE READ

Transaction isolation level setting

//查看当前事物级别：
SELECT @@tx_isolation;

//设置mysql的隔离级别：
//set session transaction isolation level 设置事务隔离级别

//设置read uncommitted级别：
set session transaction isolation level read uncommitted;

//设置read committed级别：
set session transaction isolation level read committed;

//设置repeatable read级别：
set session transaction isolation level repeatable read;

//设置serializable级别：
set session transaction isolation level serializable;

Java code to obtain and set the isolation level (conn below is the Connection object, the specific implementation will not be organized)

//获取数据库事务隔离级别
int transactionIsolation = conn.getTransactionIsolation();
//设置数据库事务隔离级别；事务隔离级别：TRANSACTION_READ_COMMITTED
conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);