Spring transaction propagation properties and isolation levels

One, propagation (the propagation property of a transaction)

The Propagation:key property determines which method the agent should add the transaction behavior to. The most important part of such a property is the propagation behavior. The following options are available: propagation_required--supports the current transaction and creates a new transaction if no transaction is currently in use. This is the most common choice.
propagation_supports--supports the current transaction and is executed in a non-transactional manner if no transaction is currently in use.
The propagation_mandatory--supports the current transaction and throws an exception if there is no current transaction.
propagation_requires_new--a new transaction, suspending the current transaction if a transaction is currently present.
The propagation_not_supported--executes the operation in a non-transactional manner, suspending the current transaction if a transaction is currently present.
The propagation_never--is executed in a non-transactional manner and throws an exception if a transaction is currently present.

1:propagation_required
Join the transaction that is currently being executed is not in another transaction, then a new transaction
For example, Serviceb.methodb's transaction level is defined as propagation_required, and because of the execution of Servicea.methoda,
Servicea.methoda has already started the transaction, when the call Serviceb.methodb,serviceb.methodb see that he has run in Servicea.methoda
Transaction, no new transactions will be started. And if Servicea.methoda is running and finds himself not in a transaction, he assigns himself a transaction.
In this way, the transaction will be rolled back if an exception occurs in the Servicea.methoda or anywhere within the SERVICEB.METHODB. Even if Serviceb.methodb's affairs have been
Commit, but Servicea.methoda will roll back in the next fail, SERVICEB.METHODB will also roll back

2:propagation_supports
If you are currently running in a transaction, that is, as a transaction, if you are not currently in a transaction, run as a non-transactional


3:propagation_mandatory
Must run in a transaction. In other words, he can only be called by a parent transaction. Otherwise, he's going to throw an exception.

4:propagation_requires_new
That's a bit of a detour. For example, we design Servicea.methoda with a transaction level of Propagation_required,serviceb.methodb of Propagation_requires_new,
Then when the execution to Serviceb.methodb, Servicea.methoda the transaction will be suspended, Serviceb.methodb will start a new transaction, waiting for the completion of the SERVICEB.METHODB transaction,
He just went on with the execution. The difference between his affairs and Propagation_required is the degree of rollback of the transaction. Because Serviceb.methodb is a new business, there is
Two different transactions. If the SERVICEB.METHODB has been committed, then Servicea.methoda fails to rollback, SERVICEB.METHODB is not rolled back. If the serviceb.methodb fails to roll back,
If the exception he throws is captured by Servicea.methoda, the Servicea.methoda transaction may still be committed.

5:propagation_not_supported
Transactions are not currently supported. For example, Servicea.methoda's transaction level is propagation_required, and Serviceb.methodb's transaction level is propagation_not_supported,
Then when execution to Serviceb.methodb, Servicea.methoda's transaction hangs, and he runs out of non-transactional state, and then continues the Servicea.methoda transaction.

6:propagation_never
Cannot run in a transaction. Suppose the transaction level of Servicea.methoda is propagation_required, and Serviceb.methodb's transaction level 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 another transaction, which will be independent of his father's affairs,
and nested's affairs are dependent on his father's affairs, and his submission is to be submitted as a piece of his father's business. In other words, if the parent transaction is finally rolled back, he will also be rolled back.
The advantage of nested affairs is that he has a savepoint.

ServiceA {/** * Transaction property is configured as propagation_required */void MethodA () {try {//savepoint Serviceb.methodb ();        propagation_nested level} catch (Someexception) {//Perform other business, such as SERVICEC.METHODC (); }    }}

That is, SERVICEB.METHODB failure rollback, then Servicea.methoda will also roll back to SavePoint point, Servicea.methoda can choose another branch, such as
SERVICEC.METHODC, go ahead and try to do your own business.
However, this transaction is not defined in the EJB standard.

Isolation level for spring transactions
1. Isolation_default: This is a platfromtransactionmanager default isolation level, using 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 a transaction, which allows a foreign transaction to see the uncommitted data for this transaction.
This isolation level produces dirty reads, non-repeatable reads, and Phantom reads.
3. isolation_read_committed: Ensure that a transaction modified data is committed before it can be read by another transaction. Another transaction cannot read uncommitted data for the transaction
4. Isolation_repeatable_read: This transaction isolation level prevents dirty reads and cannot be read repeatedly. However, Phantom reads may occur.
In addition to ensuring that one transaction cannot read uncommitted data from another transaction, it ensures that the following conditions are avoided (non-repeatable read).
5. Isolation_serializable This is the most cost-effective, but most reliable, transaction isolation level. Transactions are processed for sequential execution.
In addition to preventing dirty reading, non-repeatable reading, but also avoids phantom reading.

What is dirty data, dirty reading, non-repeatable reading, hallucination reading?
Dirty read: Refers to when a transaction is accessing the data, and the data has been modified, and this modification has not been committed to the database, at this time,
Another transaction accesses the data and then uses that data. Since this data is data that has not yet been submitted, another
The data that is read by a transaction is dirty, and the operation based on dirty data may not be correct.

Non-repeatable read: Refers to reading the same data multiple times within a transaction. When this transaction is not finished, another transaction accesses the same data.
Then, between the two read data in the first transaction, the data that was read two times by the first transaction because of the modification of the second transaction
May not be the same. This occurs when the data that is read two times within a transaction is not the same and is therefore called non-repeatable read.

Illusion reading: A phenomenon that occurs when a transaction is not executed independently, for example, when the first transaction modifies data in a table, this modification involves
To all rows of data in the table. At the same time, the second transaction modifies the data in the table by inserting a new row of data into the table. So
In the future, the user who operates the first transaction finds that there are no modified rows of data in the table, as if the illusion had occurred.

Spring transaction propagation properties and isolation levels