Spring thing propagation attribute and thing isolation level

1. propagation (transaction propagation attribute)
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.
Level (transaction isolation Level ):

Ii. Isolation Level (transaction Isolation Level ):
1. Serializable: the Serializable problem is solved when the transaction is executed Serializable (one by one), but the resource consumption is the largest; the efficiency is the lowest

2. Repeatable Read: ensures that one 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. Ommited: the default transaction level of most mainstream databases. The default transaction level of most mainstream databases ensures that a transaction is not read.

3. Read Commited the default transaction level of most mainstream databases to the data that has been modified but not committed by another parallel transaction, avoiding "Dirty reading ". This level applies to a large number of systems. 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. I will not discuss it here.

First, let's talk about the third unpleasant thing that may happen in concurrency.
1: dirty reads -- read dirty data. That is to say, for example, the uncommitted (still cached) of transaction a-the data that reads dirty data is read by transaction B. If transaction a fails to roll back, the data read by transaction B is incorrect.
2: non-repeatable reads -- data cannot be read repeatedly nonreads -- data cannot be read repeatedly. For example, if transaction a reads data from two places-data cannot be read repeatedly-total-value. In the first read, the total value is 100, and then transaction B changes the total data to 200. When transaction a reads the data again, it turns out that the total value is 200, transaction a data is disordered.
3: Phantom reads -- phantom read data, which is similar to non-repeatable reads and is also the same as the phantom read data that is inconsistent between multiple reads in a transaction. However, non-repeatable reads is inconsistent because the dataset to be retrieved is changed (such as the total data ), however, the inconsistency of the data to be read by Phantom reads is not the change of the data set to be read, but the change of its conditional data set.
For example, select account. ID where account. Name = "ppgogo *",
6 pieces of ID are read for the first time. During the second read, because transaction B changes the name of an account from "DD" to "ppgogo1 ", the result shows 7 data records. Dirty non-repeatable Phantom reads serializable won't Repeatable read committed won't Will will reads read will uncommitted

3. The readonly flag in the readonly transaction attribute indicates that the corresponding transaction should be optimized to a read-only transaction. This is an optimization prompt. In some cases, some transaction policies can achieve significant optimization, such as using object/relational Ing tools (such as hibernate or toplink) avoid dirty checking (try to "refresh ").

4. the timeout option defines the "timeout" value in the transaction attribute and specifies the transaction timeout to several seconds. In JTA, this will be simply passed to the transaction Coordination Program of the J2EE server and will be explained accordingly.