The Propagation Behavior and isolation level of Spring transactions, and the spring transaction isolation level

The Propagation Behavior and isolation level of Spring transactions, and the spring transaction isolation level

1. propagation of transactions

In the use of transactions, the most widely used Propagation Behavior is require. In most mis systems, you can switch a require transaction to the entire business layer to meet your needs.

However, spring provides not only this, but also the corresponding transaction Propagation Behavior for complex businesses to meet business needs.

The Propagation Behavior in Spring is as follows:

Require: supports the current transaction. If there is no transaction, create a new one, which is the most common;

Supports: Supports the current transaction. If there is no transaction currently, it will be executed in non-transaction mode;

Mandatory: supports the current transaction. If no transaction exists, an exception is thrown;

RequiresNew: Creates a transaction. If a transaction exists, the current transaction is suspended;

NotSupported: The operation is performed in non-transaction mode. If there is a transaction, the transaction is suspended;

Never: runs in non-transaction mode. If a transaction exists, an exception is thrown.

Nested: Creates a transaction. If a transaction exists, the current transaction is suspended. The difference with RequireNew is that it is related to the parent transaction and has a savepoint.

Here, Require, Supports, NotSupported, and Never can understand the text. Mandatory requires that all operations be performed in one transaction, which is stricter than Require.

RequireNew: When A Require method A calls RequireNew Method B, Method B creates A new transaction and the transaction has no relationship with transaction A. That is to say, Method B has an exception, it will not cause A rollback. Similarly, when B has been submitted, A will encounter an exception and B will not roll back.

Nested: the difference between this and RequireNew is that the transaction of Method B is related to the transaction of method. Only when transaction A is committed will transaction B be committed. That is to say, when A encounters an exception, transactions A and B are rolled back, and B is rolled back when B encounters an exception, and A is rolled back to the savepoint, as shown in the following code:

Public void A () {// operation 1 // operation 2 // operation 3 try {// savepoint B (); // A Nested method} catch {// exception occurs, Method B is rolled back, and method A is rolled back to // savepoint, that is to say, operations 1, 2, and 3 are still in C ();} finally {}}

2. transaction isolation level
After talking about the transaction Propagation Behavior, let's talk about the emergence of the transaction isolation level and transaction isolation level so that you can strike a balance between performance and data effectiveness, not to say that the higher the level, the better, only the right is the best.

The transaction isolation level is as follows:

Serializable: the strictest level. The transaction is executed serially, with the largest resource consumption;

Repeatable Read: ensures that a transaction does not modify the data that has been Read by another transaction but has not been committed (rolled back.

Read Committed: the default transaction level of most mainstream databases, ensuring that one transaction does not Read data that has been modified but not Committed by another parallel transaction. Applicable to most systems.

Read Uncommitted: this ensures that no illegal data is Read during the Read process.

To understand these four levels, you also need to know three undesirable things:

Dirty reads: dirty read, that is, the uncommitted data of transaction A is read by transaction B. If transaction A fails to roll back, the data read by transaction B is incorrect.

Non-repeatable reads: it cannot be read repeatedly, that is, transaction A reads data from two places. The first read time is 100, then transaction B changes the value to 200, and transaction A reads data again, the result shows that the value has changed, causing data confusion in transaction.

Phantom read: phantom read, similar to non-repeated read, is also a problem of multiple read inconsistencies in the same transaction. However, the inconsistency between non-repeated reads is because the dataset to be read is changed, while the inconsistency between the data to be read by Phantom reads is not the change of the data to be read, but its conditional dataset changes. For example, if Select id where name = "ppgogo *" is selected, six qualified IDs are read for the first time, transaction B changes the name of the first post from "dd" to "ppgo9", and seven data records are obtained.

The isolation level of the transaction may result in the reading of illegal data as follows:

How can spring transactions be performed? Isolation level and Propagation Behavior of spring transactions

1. Propagation
The key attribute determines which method the proxy should add transaction behavior. The most important part of this attribute is the Propagation Behavior. The following options are available:
PROPAGATION_REQUIRED -- supports the current transaction. If no transaction exists, a new transaction is created. This is the most common choice.
PROPAGATION_SUPPORTS -- supports the current transaction. If no transaction exists, it is executed in non-transaction mode.
PROPAGATION_MANDATORY -- supports the current transaction. If no transaction exists, an exception is thrown.
PROPAGATION_REQUIRES_NEW -- creates a transaction. If a transaction exists, it is suspended.
PROPAGATION_NOT_SUPPORTED -- executes operations in non-transaction mode. If a transaction exists, the current transaction is suspended.
PROPAGATION_NEVER -- runs in non-transaction mode. If a transaction exists, an exception is thrown.
2. Isolation Level (transaction Isolation Level ):
1. Serializable: the strictest level. The transaction is executed serially, with the largest resource consumption;
2. repeatable read: ensures that a transaction does not modify the data that has been READ by another transaction but has not been committed (rolled back. This avoids "Dirty reading" and "non-repeated reading", but results in more performance losses.
3. read committed: the default transaction level of most mainstream databases, which ensures that one transaction does not READ the modified but not COMMITTED data of another parallel transaction, avoiding "Dirty reading ". This level applies to most systems.
4. Read Uncommitted: this ensures that no illegal data is Read during the Read process.
The isolation level lies in the concurrent processing of multiple transactions. We know that parallel processing can improve the throughput and efficiency of the database, but not all concurrent transactions can run concurrently. This requires you to view the serializable condition judgment of the database textbook.
 
Spring's Propagation Behavior and isolation level

When using Spring, most of them will use its declarative transactions, simple rule configuration in the configuration file, and the use of Spring's AOP function can easily deal with transaction problems; this involves the Propagation attribute of a transaction. It is defined in the TransactionDefinition interface for PlatfromTransactionManager. PlatfromTransactionManager is the core interface of spring transaction management.

TransactionDefinition
Public interface TransactionDefinition {
Int getPropagationBehavior ();
Int getIsolationLevel ();
Int getTimeout ();
Boolean isReadOnly ();
}

The getTimeout () method returns the number of seconds that the transaction must be completed.

IsReadOnly (): whether the transaction is read-only. The transaction manager can optimize the transaction based on the returned value to ensure that the transaction is read-only.

The getIsolationLevel () method returns the isolation level of the transaction. The transaction manager controls the data in another transaction according to it.

The TransactionDefinition interface defines five different transaction isolation levels. ISOLATION_DEFAULT is a default isolation level of PlatfromTransactionManager, which uses the default transaction isolation level of the database. the other four correspond to the JDBC isolation level. ISOLATION_READ_UNCOMMITTED is the lowest isolation level of the transaction. It allows others to see the uncommitted data of this transaction. This isolation level will generate dirty reads, which cannot be repeated and Phantom reads.

There are 7 options available in the TransactionDefinition interface:

PROPAGATION_REQUIRED: supports the current transaction. If no transaction exists, a new transaction is created. This is the most common choice.

PROPAGATION_SUPPORTS: supports the current transaction. If no transaction exists, it is executed in non-transaction mode.

PROPAGATION_MANDATORY: supports the current transaction. If no transaction exists, an exception is thrown.

PROPAGATION_REQUIRES_NEW: Creates a transaction. If a transaction exists, it is suspended.

PROPAGATION_NOT_SUPPORTED: executes operations in non-transaction mode. If a transaction exists, the current transaction is suspended.

PROPAGATION_NEVER: runs in non-transaction mode. If a transaction exists, an exception is thrown.

PROPAGATION_NESTED: supports the current transaction and adds a Savepoint, which is committed or rolled back synchronously with the current transaction.