Note: Spring can control not only transaction propagation behavior (PROPAGATION_REQUIRED, etc.), but also transaction isolation level (ISOLATION_READ_UNCOMMITTED, etc.).
(The following is my personal understanding. If there are any flaws, please correct me in time.)
Let me explain in detail:
In order for everyone to understand better, let’s clarify a few knowledge points:
Transaction propagation behavior: In short, whether the transaction is submitted manually or automatically Commit, when the transaction starts and when is it committed.
Isolation level of transactions: Simply put, there are four, commit read, commit read, repeat read, and serialize read.
First, let me describe the configuration and experimental methods for transaction propagation behavior and isolation level at the database ( MySQL ) level:
Database level (using the command line): In fact, the mysql command line is very simple, I hope to experiment with it:
//Connect to the database, I am local here, followed by the username and password, don't put a semicolon, if the command doesn't work, configure the environment variables, there are many online.
1. Execute in cmd: mysql -hlocalhost -uroot -pmysql
//Check whether the local database transaction propagation behavior is manually committed (0) or automatically committed (1).
2.select @@autocommit;
//If it is 0, I want to set it to manual submission. This is actually setting the autocommit of this dialog, because if you open a cmd again, it is found that it has not been changed back. If you want to modify the global one, there is a global method on the Internet.
3.set @@autocommit=0;
//Then query a record in the local database, my local database is test1;
4.use test1;
5.select * from task where taskid=1;
//At the same time, open a new window cmd, connect to the database, and modify this record. I will not write the update statement, or directly modify this record in the database.
//Execute select * from task where taskid=1 again; find that the value has not changed. OK because the database isolation level is repeatable read at this time, because the default isolation level of mysql is repeated read.
//Modify the database isolation level
6.set global transaction isolation level read committed;
// Check it out, you may need to reconnect
7.select @@tx_isolation;
//At this time, the 4,5 operation is performed, and it is found that the value has changed, ok. Because the database isolation level has been changed, the phenomenon of repeatedly reading different data occurs.
(I hope there are those who do not understand the above operation to learn it by themselves, it is very useful, first figure out the database isolation level)
Then let's talk about the secondary encapsulation of transaction propagation behavior and isolation level by spring .
Because different projects may be on different databases of a mysql, the propagation behavior and isolation level of the database can be configured in the project:
Regarding the propagation behavior of spring (PROPAGATION_REQUIRED, PROPAGATION_REQUIRED, etc.), I have mentioned in my article "Database Isolation Level (mysql+Spring) and Performance Analysis", and there are a lot of relevant information on the Internet, so I won't talk about it.
The transaction isolation level of spring is the same as that of the database. It is also the four, and there is one more default. I will not talk about it in detail.
The following mainly talks about the configuration method of spring:
<property name="transactionAttributes">
<props>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="find*">PROPAGATION_REQUIRED,ISOLATION_READ_UNCOMMITTED</prop>
</props>
Taking find as an example, you can configure such a configuration. The front is to control the propagation behavior, and the latter is to control the transaction isolation level . At this time, even if the database level is repeated reading, it is still based on this. You will find that the results of two queries in the same transaction are different.