1 propagation properties of a transaction (propagation)
1) REQUIRED, this is the default property
Support A current transaction, create a new one if none exists.
If there is a transaction, the current transaction is supported. If there is no transaction, a new transaction is opened.
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 following method supports the current transaction, and if no transaction is currently in place, the transaction is re-established.
：
2) MANDATORY
Support A is current transaction, and throw an exception if none exists. The existing transaction is supported and throws an exception if there is no current transaction.
3) Never
Execute non-transactionally, throw an exception if a transaction exists.
Executes in a non-transactional manner, throwing an exception if a transaction is currently present.
4) not_supported
Execute non-transactionally, suspend the current transaction if one exists.
Executes the operation in a non-transactional manner, suspending the current transaction if a transaction is currently present.
5) Requires_new
Create a new transaction, suspend the current transaction if one exists.
Creates a new transaction, suspending the current transaction if the transaction currently exists.
：
6) SUPPORTS
Support A current transaction, execute non-transactionally if none exists.
Supports the current transaction and is executed in a non-transactional manner if no transaction is currently in use.
7) NESTED
Execute within a nested transaction if a current transaction exists, behave like propagation_required else.
Supports the current transaction, adds a new savepoint point, synchronously commits or rolls back with the current transaction.
Nested transactions A very important concept is that the inner transaction relies on the outer layer. When the outer transaction fails, the actions of the inner layer are rolled back. The failure of the inner transaction operation does not cause the rollback of the outer transaction.
8) The difference between propagation_nested and propagation_requires_new
They are very similar, like a nested transaction, which opens a new transaction if there is no active transaction. With Propagation_requires_new, the inner transaction and the outer transaction are like two separate transactions, and once the inner transaction commits, the outer transaction cannot roll it back. Two transactions do not affect each other. Two transactions are not a true nested transaction. It also requires the support of the JTA transaction manager.
When using propagation_nested, the rollback of the outer transaction can cause a rollback of the inner transaction. The exception of the inner transaction does not cause the rollback of the outer transaction, which is a true nested transaction.
Isolation level for 2 transactions (isolation levels)
1) First explain the three situations caused by transaction concurrency
I. Dirty Reads Dirty Reading
One transaction is updating the data, but the update has not yet been committed, and the other transaction is also manipulating the set of data and reading the data that was not committed by the previous transaction, and the previous transaction, if the operation failed, was rolled back, and the last transaction read the error data, which resulted in dirty reads.
Ii. non-repeatable Reads non-repeatable reading
A transaction reads the same data multiple times, and when the transaction is not finished, another transaction also operates on the data, and the second transaction updates the data between the first transaction two reads, and then the first transaction is read two times before the data is different, which results in non-repeatable reads.
Iii. Phantom Reads Phantom Reading
The first data is querying data that matches a certain condition, and another transaction inserts a qualifying data, and the first transaction finds data that is not in the previous query when the second query meets the same criteria, as if the illusion is a phantom read.
Iv. the difference between non-repetition and phantom reading
Non-repeating reads refer to the same query occurring more than once in the same transaction, where a non-repeating read occurs each time a different result set is returned due to modifications or deletions made by other committed transactions. (A transaction rereads data It has previously read and finds that another committed transaction have modified or deleted th E data. )
Phantom reading refers to the fact that the same query occurs more than once in the same transaction, and the phantom reads occur each time a different result set is returned because of an insert operation done by another commit. (A transaction reexecutes a query returning a set of rows that satisfies a search condition and finds that another Committ Ed transaction had inserted additional rows that satisfy the condition. )
On the surface, the difference is that non-repeating reads can see the changes and deletions that other transactions commit, while the Phantom can see the insertions that other transactions commit.
2) Default (default)
This is a Platfromtransactionmanager default isolation level that uses the default transaction isolation level of the database. The other four are relative to the JDBC isolation level
3) read_uncommitted (read not submitted)
This is the lowest isolation level for transactions, which allows another transaction to see the uncommitted data for this transaction. This isolation level produces dirty reads, non-repeatable reads, and Phantom reads.
4) read_committed (read submitted)
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. This level of transaction isolation avoids dirty reads, but non-repeatable reads and phantom reads can occur.
5) Repeatable_read (repeatable reading)
This level of transaction isolation prevents dirty reads and cannot be read repeatedly. However, Phantom reads may occur. It guarantees non-repeatable reads in addition to ensuring that one transaction cannot read uncommitted data from another transaction.
6) SERIALIZABLE (serialization)
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.
7) Isolation level resolves issues caused by transaction parallelism
Dirty reads non-repeatable reads Phantom reads
Serializable not going to be
Repeatable READ will not be
READ COMMITTED will not be
Read UNCOMMITTED will be
Introduction to the act of spreading things:
@Transactional (propagation=propagation.required)
If there is a transaction, then join the transaction and create a new one (by default)
@Transactional (propagation=propagation.not_supported)
Container does not open transactions for this method
@Transactional (propagation=propagation.requires_new)
Creates a new transaction regardless of whether a transaction exists, the original hangs, the new execution completes, and the old transaction continues
@Transactional (Propagation=propagation.mandatory)
Must be executed in an existing transaction, or throw an exception
@Transactional (Propagation=propagation.never)
Must be executed in a non-transaction, otherwise throws an exception (as opposed to propagation.mandatory)
@Transactional (Propagation=propagation.supports)
If the other bean calls this method and declares the transaction in another bean, the transaction is used. If the other bean does not declare the transaction, then there is no transaction.
Things timeout settings:
@Transactional (timeout=30)//default is 30 seconds
Transaction ISOLATION Level:
@Transactional (isolation = isolation.read_uncommitted)
READ UNCOMMITTED data (dirty read, non-repeatable read) basic not used
@Transactional (isolation = isolation.read_committed)
Read committed data (non-repeatable read and Phantom reads occur)
@Transactional (isolation = isolation.repeatable_read)
REPEATABLE READ (phantom read occurs)
@Transactional (isolation = isolation.serializable)
Serialization
MYSQL: Default to Repeatable_read level
SQL Server: Default is read_committed
Dirty reads : One transaction reads uncommitted update data to another transaction
non-repeatable read : In the same transaction, multiple reads of the same data are returned with different results, in other words,
Subsequent reads can be read to the updated data submitted by another transaction. Conversely, "repeatable reads" are repeated in the same transaction
When reading data, it is guaranteed to read the same data, that is, subsequent reads cannot be read to another transaction committed update data
Phantom reads : One transaction reads the insert data that has been committed by another transaction
About nesting things
Perhaps everyone to propagation_nested still do not know, think it is necessary to add ^_^!
Propagation_nested: The nested transaction type is relative to the six cases mentioned above (the six above should be called a flat transaction type), for example I now have a transaction mainly have a few parts:
1, minus 100 dollars from a user account
2, add 100 dollars to the B user account
This is different from the previous transaction may be no difference, I now have a special request is that a user has 3 accounts, B users have 2 accounts, now my requirement is as long as a user's 3 account of any one minus 100 yuan, to B users of two accounts in any one of the increase of 100 yuan on it!
Once you have this requirement, the nested transaction type is perfect for you! We can understand that,
One: "Subtract 100 dollars from a user account" and "add 100 yuan to the B user account" We think for the time being a first-level transaction operation
Two: will be from a user's 3 account of any one of the accounts to reduce the money as a "from a user account minus 100 yuan" sub-transaction (secondary transaction), the same as the back of the savings as another two-level transaction.
Question one: When level two transactions are rollback first-level transactions will not be rollback?
The answer is no, the rollback of the second-level business is only for oneself.
Question two: When will this level of business commit and when would it be rollback?
We mainly look at the situation in level two, when all the two-level transactions are commit and the first-level transaction does not have a failed operation, the whole transaction is a successful transaction, in which case the entire transaction will be commit.
When any two-level transaction is not commit the whole transaction is a failure, and the whole transaction is roolback.
Let's take the example above to illustrate it! If I am in a three account of the operation of the reduction of money by the second level of business to rollback, that is, 3 accounts have not lost money to succeed, the whole business will be rollback failure. If a user account has three accounts with one account that can deduct money and a user of B has two accounts in it, there can be an increase in the money, and if the whole business succeeds, it will be a commit.
Look at the above example seems to be not very deep, look at the situation (a user's 3 accounts have a credit limit, that is, can be overrun, but the amount of overspending is limited). But the principle is the same, simple point to explain a bit, I wish you good luck! ^_^
Spring transaction propagation properties and isolation levels
