1. Propagation)
1) required. This is the default attribute.
Support a current transaction, create a new one if none exists.
If a transaction exists, the current transaction is supported. If no transaction exists, a new transaction is started.
When set to this level, a logical transaction domain is created for each called method. If the previous method has already created a transaction, the subsequent method supports the current transaction. If there is no transaction, the transaction will be re-created.
:
2) Mandatory
Support a current transaction, throw an exception if none exists. The current transaction is supported. If no transaction exists, an exception is thrown.
3) Never
Execute non-transactionally, throw an exception if a transaction exists.
It is executed in non-transaction mode. If a transaction exists, an exception is thrown.
4) not_supported
Execute non-transactionally, suspend the current transaction if one exists.
The operation is performed in non-transaction mode. If a transaction exists, the current transaction is suspended.
5) requires_new
Create a new transaction, suspend the current transaction if one exists.
Create a new transaction. If a transaction exists, the current transaction is suspended.
:
6) Supports
Support a current transaction, execute non-transactionally if none exists.
Supports the current transaction. If no transaction exists, it is executed in non-transaction mode.
7) nested
Execute within a nested transaction if a current transaction exists, behave like propagation_required Else.
Supports the current transaction and the savepoint, which is committed or rolled back synchronously with the current transaction.
An important concept of nested transactions is that the inner transaction depends on the outer transaction. When an outer transaction fails, the action performed by the internal transaction is rolled back. The failure of the internal transaction operation does not cause the rollback of the outer transaction.
8) Difference between propagation_nested and propagation_requires_new
They are very similar, like a nested transaction. If there is no active transaction, a new transaction will be started. When propagation_requires_new is used, the internal transaction and the outer transaction are like two independent transactions. Once the internal transaction is committed, the outer transaction cannot roll back it. Two transactions do not affect each other. Two transactions are not a real nested transaction. It also requires support from the JTA Transaction Manager.
When propagation_nested is used, the rollback of the outer transaction can cause the rollback of the inner transaction. The exception of the internal transaction does not cause the rollback of the outer transaction. It is a real nested transaction.
2. transaction isolation level (isolation level)
1) First, describe three situations caused by transaction concurrency.
I. Dirty reads dirty read
One transaction is updating the data, but the update has not yet been committed. Another transaction is also operating on this set of data and reading the data that has not been committed by the previous transaction, if the previous transaction fails to be rolled back, the latter transaction reads the wrong data, which causes dirty reads.
Ii. non-repeatable reads cannot be read repeatedly
A transaction reads the same data multiple times. When the transaction is not finished, another transaction also operates on the data, and between two reads of the first transaction, when the second transaction updates the data, the data read twice before and after the first transaction is different, resulting in non-repeated read.
Iii. Phantom reads phantom read
The first data is querying data that meets a certain condition. At this time, another transaction inserts a data that meets the condition. When the first transaction queries data that meets the same condition for the second time, I found that there was an additional piece of data that was not found during the previous query, as if it were an illusion. This is a phantom read.
Iv. Differences between non-repetition and phantom reading
Non-repeated read refers to the process where the same query is performed multiple times in the same transaction. Because of the modifications or deletions made by other commit firms, different result sets are returned each time. In this case, non-repeated read occurs. (A transaction rereads data it has previusly read and finds that another committed transaction has modified or deleted the data .)
Phantom read refers to a query that is performed multiple times in the same transaction. Because of the insert operations performed by other commit firms, different result sets are returned each time. In this case, phantom read occurs. (A transaction reexecutes a query returning a set of rows that satisfies a search condition and finds that another committed transaction
Has inserted additional rows that satisfy the condition .)
On the surface, the difference is that non-repeated reads can see the modifications and deletions committed by other transactions, while phantom can see the inserts committed by other transactions.
2) default (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 JDBC isolation level.
3) read_uncommitted (read uncommitted)
This is the lowest isolation level of the transaction. It allows another transaction to see the uncommitted data of this transaction. This isolation level will generate dirty reads, which cannot be repeated and Phantom reads.
4) read_committed (Read committed)
Ensure that the modified data of one transaction can be read by another transaction only after it is committed. Another transaction cannot read the uncommitted data of the transaction. This transaction isolation level can avoid dirty reads, but may cause non-repeated reads and Phantom reads.
5) repeatable_read (repeatable)
This transaction isolation level prevents dirty reads and does not allow repeated reads. However, phantom reading may occur. In addition to ensuring that one transaction cannot read the data not committed by another transaction, it also ensures that the data cannot be read repeatedly.
6) serializable)
This is the most costly but most reliable transaction isolation level. Transactions are processed in sequence. In addition to preventing dirty reads and not repeated reads, Phantom reads are also avoided.
7) isolation level solves problems caused by parallel transactions
Dirty reads non-repeatable reads Phantom reads
Serializable will not
Repeatable read will not
Read committed will not
Read uncommitted will read this article from: http://www.open-open.com/lib/view/open1359693964192.html
