Isolation level of spring transactions

1. Propagation (transaction propagation property)

Propagation: The key property determines which method the agent should add transaction behavior to. The most important part of such a property is the propagation behavior. The following options are available: PROPAGATION_REQUIRED--support the current transaction, if there is no current transaction, create a new transaction. This is the most common choice.
PROPAGATION_SUPPORTS--Support the current transaction, if there is no current transaction, it will be executed in a non-transactional manner.
PROPAGATION_MANDATORY--Supports the current transaction, if there is no current transaction, an exception is thrown.
PROPAGATION_REQUIRES_NEW--Create a new transaction, if there is a current transaction, suspend the current transaction.
PROPAGATION_NOT_SUPPORTED--Perform the operation in a non-transactional manner, suspending the current transaction if there is a current transaction.
PROPAGATION_NEVER--Execute in a non-transactional manner, throwing an exception if there is currently a transaction.

1: PROPAGATION_REQUIRED
is added to the transaction currently being executed is not in another transaction, then a new transaction is started.
For example , the transaction level of ServiceB.methodB is defined as PROPAGATION_REQUIRED, then when ServiceA.methodA is executed,
ServiceA.methodA has already started After the transaction is completed, ServiceB.methodB is called at this time. ServiceB.methodB sees that it is already running inside
the transaction of ServiceA.methodA, so it will not start a new transaction. And if ServiceA.methodA runs and finds that he is not in a transaction, he will assign himself a transaction.
This way, if an exception occurs in ServiceA.methodA or anywhere within ServiceB.methodB, the transaction will be rolled back. Even if the transaction of ServiceB.methodB has been
committed , but ServiceA.methodA will fail to roll back next, ServiceB.methodB will also roll back

2: PROPAGATION_SUPPORTS
If it is currently in a transaction, it runs in the form of a transaction, if there is no longer a In a transaction, then run in a non-transactional form


3: PROPAGATION_MANDATORY
must be run in a transaction. That is, he can only be called by a parent transaction. Otherwise, he will throw exception

4: PROPAGATION_REQUIRES_NEW
This is a bit of a twist. For example, we design the transaction level of ServiceA.methodA to be PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB to be PROPAGATION_REQUIRES_NEW,
then when ServiceB.methodB is executed, the transaction where ServiceA.methodA is located will hang, and ServiceB.methodB will start a new one Transaction, waits for ServiceB.methodB's transaction to complete before
he continues to execute. The difference between him and the PROPAGATION_REQUIRED transaction is the degree of rollback of the transaction. Because ServiceB.methodB is a new transaction, then there are
two different transactions. If ServiceB.methodB has been submitted, then ServiceA.methodA fails and rolls back, but ServiceB.methodB will not roll back. Rollback if ServiceB.methodB fails,
If the exception he throws is caught by ServiceA.methodA, the ServiceA.methodA transaction may still commit.

5: PROPAGATION_NOT_SUPPORTED
Transactions are not currently supported. For example, the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB is PROPAGATION_NOT_SUPPORTED,
then when ServiceB.methodB is executed, the transaction of ServiceA.methodA is suspended, and he finishes running in a non-transactional state, and then continues ServiceA .methodA's transaction.

6: PROPAGATION_NEVER
cannot run within a transaction. Assuming that the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB is PROPAGATION_NEVER,
then ServiceB.methodB will throw an exception.

7: PROPAGATION_NESTED
The key to understanding Nested is savepoint. The difference between him and PROPAGATION_REQUIRES_NEW is that PROPAGATION_REQUIRES_NEW starts another transaction, which will be independent of his parent transaction,
while Nested's transaction is dependent on his parent transaction, and his submission is to be submitted together with his parent transaction. . That is, if the parent transaction rolls back last, he will also roll back.
And the nice thing about Nested affairs is that he has a savepoint.
****************************************
ServiceA {

/**
* The transaction property is configured as PROPAGATION_REQUIRED
*/
void methodA() {
try {
//savepoint
ServiceB.methodB(); //PROPAGATION_NESTED level
} catch (SomeException) {
// Execute other business, such as ServiceC.methodC( );
}
}

}
********************************************
also That is to say, if ServiceB.methodB fails and rolls back, then ServiceA.methodA will also roll back to the savepoint point. ServiceA.methodA can choose another branch, such as
ServiceC.methodC, and continue to execute to try to complete its own transaction.
But this transaction is not defined in the EJB standard.

Isolation level of Spring transactions
1. ISOLATION_DEFAULT: This is the default isolation level of PlatfromTransactionManager, which uses the default transaction isolation level of the database.
      The other four correspond to the isolation level of JDBC.
2. ISOLATION_READ_UNCOMMITTED: This is the lowest isolation level of transactions, which fully A transaction outside the license can see the uncommitted data of this transaction.
      This isolation level produces dirty reads, non-repeatable reads and phantom reads.
3. ISOLATION_READ_COMMITTED: To ensure that the data modified by one transaction can only be read by another transaction after it is committed. Another transaction cannot read the uncommitted data of the transaction
4. ISOLATION_REPEATABLE_READ: This transaction isolation level can prevent dirty reads and non-repeatable reads. However, phantom reads may occur.
      In addition to ensuring that a transaction cannot read uncommitted data of another transaction, it also ensures that the following situation (non-repeatable read) is avoided.
5. ISOLATION_SERIALIZABLE This is the most expensive but most reliable transaction isolation level. Transactions are processed for sequential execution.
      In addition to preventing dirty reads, non-repeatable reads, it also avoids phantom reads.

What is dirty data, dirty read, non-repeatable read, phantom read?
Dirty read: Refers to when a transaction is accessing data and making modifications to the data, and the modification has not been submitted to the database, at this time,
     another transaction also accesses the data and then uses the data. Because this data is uncommitted data, the data read by
     another transaction is dirty data, and operations based on dirty data may be incorrect.
  
Non-repeatable read: Refers to reading the same data multiple times within a transaction. While this transaction is not over, another transaction also accesses the same data.
             Then, between two reads of data in the first transaction, due to the modification of the second transaction, the data read twice by the first transaction
             may be different. In this way, the data read twice in a transaction is different, so it is called non-repeatable read.
          
Illusionary reading: Refers to a phenomenon that occurs when transactions are not executed independently, for example, the first transaction modifies data in a table, and this modification involves
         all data rows in the table. At the same time, the second transaction also modifies the data in this table by inserting a new row of data into the table. Then,
         it will happen later that the user who operates the first transaction finds that there are no modified data rows in the table, as if a hallucination occurred.