affairs

Concept: a series of indivisible operations (sql), either all executed or none executed

1. ACID

ACID : Atomicity, consistency, isolation, durability
- Atomic:
  - A transaction must be the same atomic operation sequence unit. During one execution, all operations included in the transaction will either succeed at the same time or not be executed at all. If any one of them fails, the entire transaction will be rolled back. Only if all operations are executed successfully, The whole transaction is a success
- Consistency:
  - The execution of a transaction cannot destroy the integrity and consistency of the database data. The database must be in a consistent state before and after the transaction is executed.
- Isolation isolation:
  - In a concurrent environment, concurrent transactions are isolated from each other, and the execution of one transaction cannot be interfered with by other transactions.
  - That is, when different transactions concurrently manipulate the same data, each transaction has its own complete data space. That is, the operations and data used within a transaction are isolated from other concurrent transactions, and transactions executed concurrently cannot interfere with each other. .
- Durability Persistence:
  - Durability, also called permanence, means that once a transaction is submitted, its changes to the state of the corresponding data in the database should be permanent.
  - Even in the event of a system crash or machine downtime, as long as the database can be restarted, it can be restored to the state it was in when the transaction ended successfully.

2. SQL’s 4 isolation levels:

isolation level	Dirty Read (DirtyRead)	NonRepeatableRead (NonRepeatableRead)	Phantom Read (PhantomRead)
Read uncommitted	possible	possible	possible
Read committed	impossible	possible	possible
Repeatable read	impossible	impossible	possible
Serializable	impossible	impossible	impossible

Read uncommitted:
1. If a transaction is processing each transaction and updating it, but at the same time it has not completed the transaction, or the transaction has not committed, at the same time, another transaction is allowed to access the data
2. For example: A accumulates the variable n from 0 to 10 before submitting the transaction. At this time, B may read all the intermediate values of the n variable from 0 to 10.
3. Dirty reads are allowed . Under the read uncommitted isolation level, dirty reads are allowed.
4. Dirty read refers to reading uncommitted data of other transactions.
5. Uncommitted means that the data may be rolled back, that is, it may not be stored in the database in the end, that is, non-existent data
6. **Dirty read: **Read data that does not necessarily exist in the end, this is dirty read
Read to submit:
1. Only submitted data is allowed to be read.
2. That is, in the process of transaction A accumulating n from 0 to 10, B cannot see the intermediate value of n, but can only see 10
3. Under the read committed isolation level, dirty reads are prohibited , but non-repeatable reads are allowed
4. Transaction A reads the same data multiple times, but transaction B updates and commits the data during the multiple reads of transaction A. As a result, when transaction A reads the same data multiple times, the results are inconsistent.
5. **Non-repeatable read:** refers to the situation where within a transaction, the data initially read is inconsistent with the same batch of data read at any time before the end of the transaction.
Repeatable reading:
1. It is guaranteed that during transaction processing, when the same data is read multiple times, its value is consistent with the start time of the transaction.
2. Under the repeatable read isolation level, dirty reads and non-repeatable reads are prohibited . However, phantom reads are allowed.
3. In repeatable reading, after the SQL reads the data for the first time, the data is locked (pessimistic lock). Other transactions cannot modify the data, and repeatable reading can be achieved.
4. **Phantom reading:** But this method cannot lock the insert data, so when transaction A reads the data before, or modifies all the data, transaction B can still submit the insert data, and then transaction A will find Inexplicably, there is an extra piece of data that was not available before. This is a phantom read and cannot be avoided through row locks.
5. Phantom reading is generally solved using MVCC (Multiple Version Concurrency Control)
Can be read serially:
1. The most strict transaction requires that all transactions be executed serially and cannot be executed concurrently.
2. Add a shared lock when reading, that is, other transactions can read concurrently, but cannot write. Add an exclusive lock when writing, and other transactions cannot write or read concurrently.

The difference between phantom read and non-repeatable read:

Phantom reading: In the same transaction and under the same conditions, the number of records retrieved from two queries is different;

Non-repeatable read: In the same transaction and under the same conditions, the data queried twice is different;

3. Transaction isolation level setting

Check the transaction isolation level: in MySQL8 this parameter is transaction_isolation , in MySQL5 this parameter is tx_isolation

MySQL5：
-- 查看系统隔离级别：
SELECT @@global.transaction_isolation;

-- 查看当前会话隔离级别
SELECT @@transaction_isolation;

-- 设置当前会话事务隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL  SERIALIZABLE;

-- 设置全局事务隔离级别
SET GLOBAL TRANSACTION ISOLATION LEVEL  READ UNCOMMITTED;

eventual consistency

4. Transaction opening command

#开启事务
begin/START TRANSACTION
#提交事务
commit;
#回滚事务
rollback

Apply table lock in innoDB

#对一张表上读锁/写锁格式
lock table 表名 read/write;
#例子
lock table tb_book read;
#查看当前会话对所有表的上锁情况
show open tables;
#释放当前会话的所有锁
unlock tables;

Upstream lock in innoDB:

MySAM cannot uplink the lock!

As long as thread 1 does not perform a transaction that commits the row operation, other threads cannot operate on the data of this row.

#方式1:通过修改进行上行锁，
update tb set name = 'zhangsan' where id = 3;

#方式2：通过查询加 for update；
select * from tb where id = 5 for update;

5. Distributed transactions

Theoretical basis of distributed transactions : CAP theorem

Consistency: The client knows that a series of operations will happen at the same time (take effect)
Availability: Every operation must end with a predictable response
Partition tolerance: Even if a single component becomes unavailable, the operation can still be completed

consistency:
1. In a distributed environment, consistency refers to the ability of multiple copies to remain consistent. Under the requirement of consistency, when a system performs an update operation in a consistent state of data, it should ensure that the data of the system is still processed in a consistent state.
2. For example, for an e-commerce system user to place an order, operations such as inventory reduction, user fund account deduction, and point increase must be consistent after the user's order is completed. There cannot be a situation like the inventory has been reduced, but the user's capital account has not been deducted and the points have not been increased. If this occurs, it is considered inconsistent.
3. Data consistency is divided into strong consistency, eventual consistency, weak consistency
  1. If it is indeed possible to ensure that the data seen by the client is consistent at all times as stated above, then it is called strong consistency
  2. If an intermediate state is allowed, and only after a period of time, the data is finally consistent, it is called final consistency
  3. In addition, if partial data inconsistency is allowed, it is called weak consistency
Availability:
1. The services provided by the system must always be available, and the results can always be returned within a limited time for each operation request of the user
2. Dimensions of two magnitudes:
  1. for a limited time
    1. For an operation request from the user, the system must be able to return the corresponding processing result within the specified time (response time). If this time range is exceeded, the system is considered unavailable . That is, the response time must be within a reasonable value so as not to disappoint users.
    2. Just imagine, if an order operation takes 10 minutes to complete in order to ensure the consistency of distributed transactions, then the user will obviously not be able to bear it, so when this happens, a downgrade circuit breaker is generally used.
  2. Returns normal results:
    1. The system is required to return a normal response result after completing processing the user's request. Normal response results usually clearly reflect the processing result of the request, that is, success or failure, rather than a return result that confuses the user. For example, if a system error such as OutOfMemory is returned, the system is considered unavailable.
    2. "Return result" is another very important indicator of availability. It requires the system to return a normal response result after completing the processing of the user's request, regardless of whether the result is success or failure.
Partition tolerance:
1. That is, when a distributed system encounters any network partition failure, it still needs to be able to ensure that it provides external services that meet the consistency and availability, unless the entire network environment fails.
2. Network partition refers to that in a distributed system, different nodes are distributed in different sub-networks (computer room/remote network). Due to some special reasons, there is a state of network disconnection between these sub-networks, but each sub-network The internal network is normal, resulting in the network environment of the entire system being divided into several isolated areas. The joining and exit of each node forming a distributed system can be regarded as a special network partition.

CAP theory tells us:

No distributed system can satisfy consistency, availability, and partition tolerance at the same time
. It can only satisfy two at most. In most scenarios in the Internet field, strong consistency needs to be sacrificed in exchange for high system availability , and the system often only needs to ensure eventual consistency.

Why can't both consistency and availability be guaranteed in a distributed system?
The first premise is that for distributed systems, partition fault tolerance is the most basic requirement, so basically we can only choose between consistency (C) and availability (A) when designing a distributed system.
If consistency is guaranteed (C): For nodes N1 and N2, when writing data to N1, the operation on N2 must be suspended. Only when N1 synchronizes data to N2 can read and write requests to N2 be made. Requests submitted by the client during the pause operation will receive a failure or timeout. Obviously, this is contrary to usability.
If availability (A) is guaranteed: then the read and write operations of N2 cannot be suspended, but if N1 is writing data at the same time, this violates the consistency requirement.

BASE theorem

Concept: CAP is a distributed system design theory, and BASE is an extension of the AP solution in the CAP theory. The methods and strategies we adopt for C are to ensure eventual consistency;

Composition: BASE is the abbreviation of the three phrases Basically Available, Soft state and Eventually consistent. BASE evolved based on the CAP theorem. The core idea is that strong consistency cannot be achieved immediately, but each application can adopt appropriate methods according to its own business characteristics to achieve final consistency of the system.

Basically Available
1. Basic availability means that the distributed system is allowed to lose part of its availability when unpredictable failures occur, but it does not mean that the system cannot be used.
2. Loss in response time
  - When a failure occurs, response time increases
3. functional loss
  - when traffic peaks. Block the use of some functions to ensure system stability (service degradation)
Soft stata (soft state)
1. It means that the data in the system is allowed to exist in an intermediate state, and it is believed that the existence of this intermediate state will not affect the overall availability of the system.
2. As opposed to the hard state, it means that the data in the system is allowed to have an intermediate state, and that the existence of the intermediate state will not affect the overall availability of the system, that is, the process of allowing the system to synchronize data between data copies of different nodes has a delay. hour.
Eventually consistent
1. It is emphasized that all data copies in the system can eventually reach a consistent state after a period of synchronization. Its essence is that the system needs to ensure that the final data can be consistent, but it does not need to ensure the strong consistency of the system data in real time.

6. Spring transaction failure

Throwing a checked exception prevents the transaction from being rolled back correctly
- Reason: spring only rolls back unchecked exceptions by default
- Solution: configure the rollbackFor attribute and set it directly toException.class
  - @Transactional(rollbackFor = Exception.class)
The try-catch exception in the business method prevents the transaction from being rolled back correctly.
- Reason: The transaction notification can only catch the exception thrown by the target before subsequent rollback processing can be performed. If the target handles the exception by itself, the transaction notification cannot be seen
- Solution: The exception is thrown as is
  - In the catch block addthrow new RuntimeException(e);
Transaction failure caused by non-public method
- Reason: Spring creates a proxy for the method and adds transaction notification. The prerequisite is that the method is public.
- Solution: Change to public

【2023】MySQL in detail - locks and transactions (1)