Spring transaction propagation and isolation level

There are 7 propagation levels of transactions:

1) PROPAGATION_REQUIRED : Support the current transaction, create a new one if there is no transaction.

2) PROPAGATION_SUPPORTS : support the current transaction, if there is no transaction, it will be processed in a non-transactional way

3) PROPAGATION_MANDATORY : support the current transaction, throw an exception if there is no transaction

4) PROPAGATION_REQUIRES_NEW : Create a new transaction, if there is a current transaction, suspend the current transaction

5) PROPAGATION_NOT_SUPPORTED : Execute the operation in a non-transactional manner, and suspend if there is a transaction

6) PROPAGATION_NEVER : processed in a non-transactional manner, if there is a transaction, it will be suspended 

7) PROPAGATTION_NESTED : If a transaction currently exists, execute within a nested transaction. If there are no current transactions, do something similar to PROPAGATION_REQUIRED

 

4 isolation levels of data:

Read uncommitted (unauthorized read, read uncommitted):

If a transaction has already started to write data, another transaction is not allowed to write at the same time, but allows other transactions to read this row of data. This isolation level can be achieved through "exclusive write locks".

Avoid lost updates, but dirty reads may occur. That is to say, transaction B has read the uncommitted data of transaction A.

Read committed (authorized read, read commit):

Transactions that read data allow other transactions to continue to access the row, but uncommitted write transactions prevent other transactions from accessing the row.

This isolation level avoids dirty reads, but non-repeatable reads are possible. Transaction A reads the data in advance, transaction B updates the data immediately, and submits the transaction, and when transaction A reads the data again, the data has changed.

Repeatable read :

Transactions that read data will prohibit write transactions (but allow read transactions), and write transactions will prohibit any other transactions.

Non-repeatable reads and dirty reads are avoided, but phantom reads can sometimes occur. This can be achieved with "shared read locks" and "exclusive write locks".


Serializable :

Provides strict transaction isolation. It requires transactions to be executed serially, transactions can only be executed one after the other, but not concurrently. If transaction serialization cannot be achieved only through "row-level locks", other mechanisms must be used to ensure that newly inserted data will not be accessed by the transaction that just executed the query operation.

Serialization is the highest transaction isolation level, but also has the highest cost, low performance, and is rarely used. At this level, transactions are executed sequentially, which not only avoids dirty reads, non-repeatable reads, but also phantom reads.


The higher the isolation level, the better the data integrity and consistency can be guaranteed, but the greater the impact on concurrent performance. For most applications, it is preferable to set the isolation level of the database system to Read Committed. It avoids dirty reads and has good concurrency performance. Although it can lead to concurrency problems such as non-repeatable reads, phantom reads, and second-class lost updates, in individual cases where such problems may occur, it can be controlled by the application using pessimistic locking or optimistic locking.

1) PROPAGATION_REQUIRED : Support the current transaction, create a new one if there is no transaction.

2) PROPAGATION_SUPPORTS : support the current transaction, if there is no transaction, it will be processed in a non-transactional way

3) PROPAGATION_MANDATORY : support the current transaction, throw an exception if there is no transaction

4) PROPAGATION_REQUIRES_NEW : Create a new transaction, if there is a current transaction, suspend the current transaction

5) PROPAGATION_NOT_SUPPORTED : Execute the operation in a non-transactional manner, and suspend if there is a transaction

6) PROPAGATION_NEVER : processed in a non-transactional manner, if there is a transaction, it will be suspended 

7) PROPAGATTION_NESTED : If a transaction currently exists, execute within a nested transaction. If there are no current transactions, do something similar to PROPAGATION_REQUIRED

 

4 isolation levels of data:

Read uncommitted (unauthorized read, read uncommitted):

If a transaction has already started to write data, another transaction is not allowed to write at the same time, but allows other transactions to read this row of data. This isolation level can be achieved through "exclusive write locks".

Avoid lost updates, but dirty reads may occur. That is to say, transaction B has read the uncommitted data of transaction A.

Read committed (authorized read, read commit):

Transactions that read data allow other transactions to continue to access the row, but uncommitted write transactions prevent other transactions from accessing the row.

This isolation level avoids dirty reads, but non-repeatable reads are possible. Transaction A reads the data in advance, transaction B updates the data immediately, and submits the transaction, and when transaction A reads the data again, the data has changed.

Repeatable read :

Transactions that read data will prohibit write transactions (but allow read transactions), and write transactions will prohibit any other transactions.

Non-repeatable reads and dirty reads are avoided, but phantom reads can sometimes occur. This can be achieved with "shared read locks" and "exclusive write locks".


Serializable :

Provides strict transaction isolation. It requires transactions to be executed serially, transactions can only be executed one after the other, but not concurrently. If transaction serialization cannot be achieved only through "row-level locks", other mechanisms must be used to ensure that newly inserted data will not be accessed by the transaction that just executed the query operation.

Serialization is the highest transaction isolation level, but also has the highest cost, low performance, and is rarely used. At this level, transactions are executed sequentially, which not only avoids dirty reads, non-repeatable reads, but also phantom reads.


The higher the isolation level, the better the data integrity and consistency can be guaranteed, but the greater the impact on concurrent performance. For most applications, it is preferable to set the isolation level of the database system to Read Committed. It avoids dirty reads and has good concurrency performance. Although it can lead to concurrency problems such as non-repeatable reads, phantom reads, and second-class lost updates, in individual cases where such problems may occur, it can be controlled by the application using pessimistic locking or optimistic locking.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324611898&siteId=291194637