Propagation Behavior and isolation level of spring transactions

7 propagation behaviors, 4 isolation levels,

Propagation Behavior and isolation level of spring transactions [transaction behavior and isolated level] Propagation Behavior and isolation level of transactions [transaction behavior and isolated level]
Definitions of transactions in Spring:
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.

Many people do not know much about the attributes of transaction propagation behaviors. I did not know about the attributes of J2EE without EJB last night, or even re-opened the database system teaching material book, however, this analysis is not found. Search for an excellent analysis today Article Although this article focuses on the analysis of propagation_required and propagation_required_nested
Spring nested transactions /**
* @ Author Wang Zheng
* @ Date 2006-11-24
* @ Note Reprinted from http://www.javaeye.com/topic/35907? Page = 1
*/******** Transactiondefinition interface definition *******************
/**
* Support a current transaction, create a new one if none exists.
* Analogous to EJB transaction attribute of the same name.
* <P> This is typically the default setting of a transaction definition.
*/
Int propagation_required = 0;

/**
* Support a current transaction, execute non-transactionally if none exists.
* Analogous to EJB transaction attribute of the same name.
* <P> Note: For transaction managers with transaction synchronization,
* Propagation_supports is slightly different from no transaction at all,
* As it defines a transaction SCOPP that synchronization will apply.
* As a consequence, the same resources (JDBC connection, Hibernate session, etc)
* Will be shared for the entire specified scope. Note that this depends on
* The actual synchronization configuration of the Transaction Manager.
* @ See org. springframework. transaction. Support. abstractplatformtransactionmanager # settransactionsynchronization
*/
Int propagation_supports = 1;

/**
* Support a current transaction, throw an exception if none exists.
* Analogous to EJB transaction attribute of the same name.
*/
Int propagation_mandatory = 2;

/**
* Create a new transaction, suspend the current transaction if one exists.
* Analogous to EJB transaction attribute of the same name.
* <P> Note: actual transaction suspension will not work on out-of-the-box
* On all transaction managers. This in particle applies to jtatransactionmanager,
* Which requires the <code> javax. transaction. transactionmanager </code> to be
* Made available it to it (which is server-specific in standard J2EE ).
* @ See org. springframework. transaction. JTA. jtatransactionmanager # settransactionmanager
*/
Int propagation_requires_new = 3;

/**
* Execute non-transactionally, suspend the current transaction if one exists.
* Analogous to EJB transaction attribute of the same name.
* <P> Note: actual transaction suspension will not work on out-of-the-box
* On all transaction managers. This in particle applies to jtatransactionmanager,
* Which requires the <code> javax. transaction. transactionmanager </code> to be
* Made available it to it (which is server-specific in standard J2EE ).
* @ See org. springframework. transaction. JTA. jtatransactionmanager # settransactionmanager
*/
Int propagation_not_supported = 4;

/**
* Execute non-transactionally, throw an exception if a transaction exists.
* Analogous to EJB transaction attribute of the same name.
*/
Int propagation_never = 5;

/**
* Execute within a nested transaction if a current transaction exists,
* Behave like propagation_required else. There is no analogous feature in EJB.
* <P> Note: actual creation of a nested transaction will only work on specific
* Transaction managers. out of the box, this only applies to the JDBC
* Datasourcetransactionmanager when working on a JDBC 3.0 driver.
* Some JTA providers might support nested transactions as well.
* @ See org. springframework. JDBC. datasource. datasourcetransactionmanager
*/
Int propagation_nested = 6;
**************************************** *********************************
In this article, he used two nested examples to assist analysis, which I directly reference here. * ******************* Sample ******************* ****
Servicea {

/**
* Set the transaction property to propagation_required.
*/
Void methoda (){
Serviceb. methodb ();
}

}

Serviceb {

/**
* Set the transaction property to propagation_required.
*/
Void methodb (){
}

}*************************************** **********
Let's analyze them one by one.
1: propagation_required
Adding the transaction to be executed is not in another transaction, so a new transaction starts.
For example, the transaction level of serviceb. methodb is defined as propagation_required,
Servicea. methoda has started the transaction. Then serviceb. methodb is called, and serviceb. methodb is called to see that it is already running in servicea. methoda.
Within the transaction, there will be no new transactions. However, if servicea. methoda finds that he is not in the transaction, it will assign a transaction to him.
In this way, the transaction will be rolled back if an exception occurs in servicea. methoda or anywhere in serviceb. methodb. Even if the serviceb. methodb transaction has been
Submit, but servicea. methoda will roll back in the next fail, and serviceb. methodb will also roll back 2: propagation_supports
If the current transaction is running in the form of a transaction, if there is no longer a transaction, it will run in the form of a non-transaction
This is similar to the common non-transactional Code There is only one difference. Ignore this, because I do not think there is any difference 3: propagation_mandatory
It must be run in a transaction. That is, it can only be called by one parent transaction. Otherwise, an exception is thrown. 4: propagation_requires_new
This is a detour. For example, the transaction level of servicea. methoda is propagation_required, and that of serviceb. methodb is propagation_requires_new,
When serviceb. methodb is executed, the transaction where servicea. methoda is located will be suspended, and serviceb. methodb will start a new transaction. After the serviceb. methodb transaction is completed,
He will continue the execution. The difference between the propagation_required transaction and propagation_required is the transaction rollback degree. Because serviceb. methodb is a new transaction, it exists.
Two different transactions. If serviceb. methodb has been submitted, servicea. methoda fails to roll back, And serviceb. methodb will not roll back. If serviceb. methodb fails to roll back,
If the thrown exception is caught by servicea. methoda, servicea. methoda transactions may still be committed. 5: propagation_not_supported
Transactions are currently not supported. For example, the transaction level of servicea. methoda is propagation_required, while that of serviceb. methodb is propagation_not_supported,
When serviceb. methodb is executed, the servicea. methoda transaction is suspended, and the servicea. methoda transaction continues after it is finished in a non-transaction state. 6: propagation_never
Cannot run in transactions. Assume that the transaction level of servicea. methoda is propagation_required, while that of serviceb. methodb is propagation_never,
Then serviceb. methodb will throw an exception. 7: propagation_nested
The key to understanding nested is savepoint. The difference between propagation_requires_new and propagation_requires_new is that another transaction will be independent of its parent transaction,
The nested transaction is dependent on his parent transaction, and his commit must be committed together with his parent transaction. That is to say, if the parent transaction is finally rolled back, it will also be rolled back.
The advantage of the nested transaction is that it has a savepoint.
**************************************** *
Servicea {

/**
* Set the transaction property to propagation_required.
*/
Void methoda (){
Try {
// Savepoint
Serviceb. methodb (); // propagation_nested level
} Catch (someexception ){
// Execute other services, such as servicec. methodc ();
}
}

}
**************************************** ****
That is to say, serviceb. methodb fails to roll back, so servicea. methoda will also roll back to the savepoint. servicea. methoda can select another branch, such
Servicec. methodc, continue to execute to try to complete your own transactions.
However, this transaction is not defined in the EJB standard.
Ii. 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.
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, if the uncommitted (still cached) data of transaction a 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. For example, transaction a reads the value of data-total-in two places. 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 inconsistent between multiple reads in the same 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 *": Six qualified IDs are read for the first time. During the second read, transaction B changes the name of an account from "DD" to "ppgogo1 ", the result shows 7 data records. Dirty reads non-repeatable reads Phantom reads
Serializable will not
Repeatable read will not
Read committed will not
Read uncommitted will
Iii. readonly
The readonly flag in the 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 passed to the J2EE server for transaction coordination. Program .