2. Understand affairs
2.1. Why transactions are needed
How to solve it使用事务
2.2. What is a transaction?
The concept of transaction:
A database transaction is a program execution unit that accesses and possibly updates various data items in the database. The
composition of a transaction:
A database transaction usually contains a sequence of operations that read or write to the database.
Related features of transactions:
-
A database transaction can contain one or more database operations, but these operations form a logical whole.
-
These database operations that form a logical whole are either all executed successfully or all are executed unsuccessfully.
-
All operations that make up a transaction either all have an impact on the database or none of them have an impact.
That is, regardless of whether the transaction is executed successfully or not, the database can always maintain a consistent state.
-
The above is true even if the database fails and concurrent transactions exist.
2.3. Solution
2.4. Transaction characteristics
3. Transaction exception
3.1. Dirty reading
Read uncommitted
3.2. Non-repeatable reading
Read submitted
3.3. Phantom reading
Statistical transactions are to query multiple pieces of data and summarize one result. It is impossible to read only one piece of data repeatedly.
4. Transaction isolation level
4.1. What is isolation level:
Problems caused by concurrent transactions operating on the same batch of data can be solved by setting the isolation level.
4.2. Classification of isolation levels (from low to high):
➢READ UNCOMMITTED ➢READ COMMITTED
– Oracle default level
➢Repeatable read (REPEATABLE READ) – MySQL default level
➢SERIALIZABLE
隔离级别从小到大安全性越来越高，但是效率越来越低
5. Transaction concurrency exception - lost updates
5.1. Lost update concept
If multiple threads operate to modify the records in the table based on the same query structure,
那么后修改的记录将会覆盖前面修改的记录，前面的修改就丢失掉了, this is called update loss.
5.2. The first type of lost update: rollback loss
All isolation levels do not allow type 1 lost updates to occur and are not considered
5.3. The second type of lost update: coverage loss
All isolation levels do not allow type 1 lost updates to occur
5.4. How to solve the second type of lost updates
5.4.1. Pessimistic locking mechanism
Assuming that such a problem is high-probability, it is best to lock it from the beginning to avoid updating errors all the time.
➢Add shared lock method: select * from account lock in share mode;
➢Add exclusive lock method: select * from account for update;
5.4.2. Optimistic locking mechanism
Assuming that such a problem is unlikely, lock it during the last update step to avoid locking for too long and affecting other people's related operations. ➢Add a timestamp field to the table and set it to update the field to the latest time
whenever the table is inserted or modified; ➢When modifying data, determine whether the current update is based on the current update by checking whether the timestamp has changed. Check whether it is an outdated version;
5.4.3. Demonstration of optimistic locking mechanism
5.4.4. How to choose between optimistic lock and pessimistic lock
Choose the pessimistic lock b method in application systems with relatively few concurrent users and serious conflicts.
In other cases, the optimistic locking version method is used first.
Here is the quote