Details of spring transaction propagation properties and isolation levels

1 propagation attribute of transaction

1) Required, this is the default attribute

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, start a new transaction.

When set to this level, a logical transaction domain will be created for each called method. If the previous method has created a transaction, the latter method supports the current transaction. If there is no transaction, the transaction will be re established.

2) MANDATORY

Support a current transaction,throw an exception if none exists. Supports the current transaction. If there is no current transaction, an exception will be thrown.

3) NEVER

Execute non-transactionally,throw an exception if a transaction exists.

Execute in a non transactional manner. If a transaction currently exists, an exception will be thrown.

4) NOT_ SUPPORTED

Execute non-transactionally,suspend the current transaction if one exists.

The operation is performed in a non transactional manner. If there is a current transaction, the current transaction is suspended.

5) REQUIRES_ NEW

Create a new transaction,suspend the current transaction if one exists.

Create a new transaction. If there is a current transaction, suspend the current transaction.

6) SUPPORTS

Support a current transaction,execute non-transactionally if none exists.

The current transaction is supported. If there is no current transaction, it will be executed in a non transactional manner.

7) NESTED

Execute within a nested transaction if a current transaction exists,behave like PROPAGATION_ required else.

Supports the current transaction, adds a savepoint, and synchronously commits or rolls back with the current transaction.

A very important concept of nested transactions is that inner transactions depend on outer transactions. When the outer transaction fails, the actions of the inner transaction will be rolled back. Inner transaction operation

Failure does not cause a rollback of the outer transaction.

8) PROPAGATION_ Nested and promotion_ REQUIRES_ New differences

They are very similar. They are like a nested transaction. If there is no active transaction, a new transaction will be opened. Using propagation_ REQUIRES_ During new, the inner transaction and the outer transaction are like two independent transactions. Once the inner transaction is committed, the outer transaction cannot be rolled back. The two transactions do not affect each other. Two transactions are not really nested transactions. At the same time, it needs the support of JTA transaction manager.

Using propagation_ When nested, the rollback of the outer transaction can cause the rollback of the inner transaction. The exception of the inner transaction does not cause the rollback of the outer transaction. It is a real nested transaction.

2. Isolation level of transactions

1) First, let's explain three situations caused by transaction concurrency

i. Dirty reads

One transaction is updating the data, but the update has not been committed. Another transaction also operates on this group of data and reads the uncommitted data of the previous transaction. If the previous transaction rolls back if the operation fails, the latter transaction reads the wrong data, resulting in dirty reading.

ii. Non repeatable reads is not repeatable

A transaction reads the same data multiple times. Before the transaction ends, another transaction also operates on the data. Moreover, between the two reads of the first transaction, the second transaction updates the data. Then the data read before and after the first transaction is different, resulting in non repeatable reading.

III. phantom reads

The first data is querying the data that meets a certain condition. At this time, another transaction inserts another qualified data. When the first transaction queries the data that meets the same condition for the second time, it finds an additional piece of data that did not exist in the previous query, as if it were an illusion. This is phantom reading.

IV. difference between non repetition and phantom reading

Non duplicate reads refer to that the same query is performed multiple times in the same transaction. Due to the modification or deletion of other submitted transactions, different result sets are returned each time. At this time, non duplicate reads occur. (A transaction rereads data it has prevIoUsly read and finds that another committed transaction has modified or deleted the data. )

Phantom reading refers to that the same query is performed multiple times in the same transaction. Due to the insertion operations performed by other committed transactions, different result sets are returned each time. Phantom reading occurs at this time. (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 repetitive reading can see the modification and deletion committed by other transactions, while phantom can see the insertion committed by other transactions.

2) Default (default)

This is the default isolation level of platfromtransactionmanager and uses the default transaction isolation level of database The other four correspond to the isolation level of JDBC

3) READ_ Uncommitted (read uncommitted)

This is the lowest isolation level of a transaction. It allows another transaction to see the uncommitted data of this transaction. This isolation level produces dirty reads, non repeatable reads, 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 non repeatable reads and phantom reads may occur.

5) REPEATABLE_ Read (repeatable)

This transaction isolation level prevents dirty reads and non repeatable reads. But phantom reading may occur. In addition to ensuring that one transaction cannot read uncommitted data from another transaction, it also ensures that it cannot be read repeatedly

6) Serializable

This is the most expensive but most reliable level of transaction isolation. Transactions are processed to execute sequentially. In addition to preventing dirty reading and non repeatable reading, phantom reading is also avoided.

7) The isolation level solves the problems caused by transaction parallelism

Dirty reads non-repeatable reads phantom reads

Serializable no

Repeatable read no

Read committed will not

Read uncommitted

Introduction to communication behavior:

@Transactional(propagation=Propagation.required)

If there is a transaction, join the transaction. If not, create a new one (by default)

@Transactional(propagation=Propagation.NOT_SUPPORTED)

The container does not open a transaction for this method

@Transactional(propagation=Propagation.REQUIRES_NEW)

No matter whether there is a transaction or not, a new transaction is created. The original transaction is suspended, the new transaction is completed, and the old transaction continues to be executed

@Transactional(propagation=Propagation.MANDATORY)

It must be executed in an existing transaction, otherwise an exception is thrown

@Transactional(propagation=Propagation.NEVER)

It must be executed in a transaction without, or an exception will be thrown (as opposed to propagation. Mandatory)

@Transactional(propagation=Propagation.SUPPORTS)

If other beans call this method and declare transactions in other beans, use transactions If other beans do not declare transactions, they do not need transactions

Transaction timeout setting:

@Transactional (timeout = 30) / / the default is 30 seconds

Transaction isolation level:

@Transactional(isolation = Isolation.READ_UNCOMMITTED)

Reading uncommitted data (dirty reading and non repeatable reading) is basically not used

@Transactional(isolation = Isolation.READ_COMMITTED)

Read committed data (non repeatable and unreal reads will occur)

@Transactional(isolation = Isolation.REPEATABLE_READ)

Repeatable reading (unreal reading will appear)

@Transactional(isolation = Isolation.SERIALIZABLE)

Serialization

MySQL: repeatable by default_ Read level

Sqlserver: the default is read_ COMMITTED

Dirty read: one transaction reads uncommitted update data from another transaction

Non repeatable reading: in the same transaction, the results returned by reading the same data multiple times are different, in other words,

Subsequent reading can read the update data committed by another transaction Instead, repeatable reads occur multiple times in the same transaction

When reading data, you can ensure that the read data is the same, that is, subsequent reads cannot read the update data committed by another transaction

Phantom read: one transaction reads the committed insert data of another transaction

About nested things

Maybe everyone is interested in promotion_ Nested doesn't know much about it. I think it's necessary to add ^ ^ ^!

PROPAGATION_ Nested: nested transaction types are relative to the six cases mentioned above (the above six should be called plane transaction types). For example, I now have a transaction, which mainly includes the following parts:

1. Subtract 100 yuan from user a's account

2. Add 100 yuan to B user account

In this way, there may be no difference between different transactions in the past. Now I have a special requirement that user a has three accounts and user B has two accounts. Now my requirement is to subtract 100 yuan from any of the three accounts of user a and add 100 yuan to any of the two accounts of user B!

Once you have such requirements, the nested transaction type is very suitable for you! We can understand this,

1： "Subtract 100 yuan from user a's account" and "add 100 yuan to user B's account" are temporarily considered as level-1 transaction operations

2： Reducing money from any of the three accounts of user a is regarded as a sub transaction (secondary transaction) of the primary transaction of "subtracting 100 yuan from user a's account". Similarly, the subsequent deposit is regarded as another secondary transaction.

Question 1: when a level 2 transaction is rolled back, will a level 1 transaction be rolled back?

The answer is No. the rollback of secondary transactions is only for themselves.

Question 2: when will this first level transaction commit and be rolled back?

We mainly look at the situation in Level 2. When all level 2 transactions are committed and there are no failed operations in level 1 transactions, the whole transaction is regarded as a successful transaction. In this case, the whole transaction will be committed.

When any secondary transaction is not committed, the whole transaction will fail and the whole transaction will be roolback.

Let's take the above example to illustrate! If the money reduction operation in the three accounts of a is rolled back by the secondary transaction, that is, if the money reduction is not successful in the three accounts, the whole transaction will fail and be rolled back. If one of the three accounts of user a can deduct money, and one of the two accounts of user B can increase money, even if the whole transaction is successful, it will be committed.

After looking at the above example, I don't think it's very profound. Look at this situation (user a's three accounts have credit lines, that is, they can overspend, but there is a limit on the amount of overspend). However, the principle is the same. It's better to explain it simply. Good luck^_^