The propagation behavior and isolation level of spring transactions

Reprinted from: http://blog.chinaunix.net/u1/55983/showart_2091761.html
7 propagation behavior, 4 isolation levels,

Propagation behavior and isolation level of spring transactions [transaction behavior and isolated level]2007-08-01 16:33 transaction propagation behavior and isolation level [transaction behavior and Isolated level]

Definition of a transaction in spring:
First, propagation:
The key property determines which method the agent should add the transaction behavior to. The most important part of such a property is the propagation behavior. The following options are available for use:
propagation_required--supports the current transaction and creates a new transaction if there is no current transaction. This is the most common choice.
propagation_supports--supports the current transaction and is executed in a non-transactional manner if no transaction is currently in use.
The propagation_mandatory--supports the current transaction and throws an exception if there is no current transaction.
propagation_requires_new--a new transaction, suspending the current transaction if a transaction is currently present.
The propagation_not_supported--executes the operation in a non-transactional manner, suspending the current transaction if a transaction is currently present.
The propagation_never--is executed in a non-transactional manner and throws an exception if a transaction is currently present.

Many people see the transactional behavior properties are not very understanding, I saw the Java EE without EJB last night, I saw here also do not understand, and even re-turn the database system textbooks, but also did not find the analysis of this. Search today to find an excellent analytical article, although this article is focused on analyzing propagation_required and Propagation_required_nested's
====================================================




FAQ Spring Nested transactions
/**
* @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.
*
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.
*

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 would apply for.
* As a consequence, the same resources (JDBC Connection, Hibernate Session, etc)
* Would be GKFX 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 is 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.
*

Note:actual transaction suspension won't work on Out-of-the-box
* on all transaction managers. This on particular applies to Jtatransactionmanager,
* which requires the Javax.transaction.TransactionManager to be
* Made available it to it (which was server-specific in standard EE).
* @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.
*

Note:actual transaction suspension won't work on Out-of-the-box
* on all transaction managers. This on particular applies to Jtatransactionmanager,
* which requires the Javax.transaction.TransactionManager to be
* Made available it to it (which was server-specific in standard EE).
* @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.
*

Note:actual creation of a nested transaction would only work on specific
* Transaction managers. Out of the box, this is 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 uses two nested examples to assist the analysis, which I quote directly here.
sample***********************
ServiceA {

/**
* Transaction properties configured to Propagation_required
*/
void MethodA () {
Serviceb.methodb ();
}

}

SERVICEB {

/**
* Transaction properties configured to Propagation_required
*/
void MethodB () {
}

}
*************************************************
1:propagation_required
Join the transaction that is currently being executed is not in another transaction, then a new transaction
For example, Serviceb.methodb's transaction level is defined as propagation_required, and because of the execution of Servicea.methoda,
Servicea.methoda has already started the transaction, when the call Serviceb.methodb,serviceb.methodb see that he has run in Servicea.methoda
Transaction, no new transactions will be started. And if Servicea.methoda is running and finds himself not in a transaction, he assigns himself a transaction.
In this way, the transaction will be rolled back if an exception occurs in the Servicea.methoda or anywhere within the SERVICEB.METHODB. Even if Serviceb.methodb's affairs have been
Commit, but Servicea.methoda will roll back in the next fail, SERVICEB.METHODB will also roll back

2:propagation_supports
If you are currently running in a transaction, that is, as a transaction, if you are not currently in a transaction, run as a non-transactional


3:propagation_mandatory
Must run in a transaction. In other words, he can only be called by a parent transaction. Otherwise, he's going to throw an exception.

4:propagation_requires_new
That's a bit of a detour. For example, we design Servicea.methoda with a transaction level of Propagation_required,serviceb.methodb of Propagation_requires_new,
Then when the execution to Serviceb.methodb, Servicea.methoda the transaction will be suspended, Serviceb.methodb will start a new transaction, waiting for the completion of the SERVICEB.METHODB transaction,
He just went on with the execution. The difference between his affairs and Propagation_required is the degree of rollback of the transaction. Because Serviceb.methodb is a new business, there is
Two different transactions. If the SERVICEB.METHODB has been committed, then Servicea.methoda fails to rollback, SERVICEB.METHODB is not rolled back. If the serviceb.methodb fails to roll back,
If the exception he throws is captured by Servicea.methoda, the Servicea.methoda transaction may still be committed.

5:propagation_not_supported
Transactions are not currently supported. For example, Servicea.methoda's transaction level is propagation_required, and Serviceb.methodb's transaction level is propagation_not_supported,
Then when execution to Serviceb.methodb, Servicea.methoda's transaction hangs, and he runs out of non-transactional state, and then continues the Servicea.methoda transaction.

6:propagation_never
Cannot run in a transaction. Suppose the transaction level of Servicea.methoda is propagation_required, and Serviceb.methodb's transaction level is Propagation_never,
Then Serviceb.methodb will throw an exception.

7:propagation_nested
The key to understanding nested is savepoint. The difference between him and propagation_requires_new is that propagation_requires_new another transaction, which will be independent of his father's affairs,
and nested's affairs are dependent on his father's affairs, and his submission is to be submitted as a piece of his father's business. In other words, if the parent transaction is finally rolled back, he will also be rolled back.
The advantage of nested affairs is that he has a savepoint.
*****************************************
ServiceA {

/**
* Transaction properties configured to Propagation_required
*/
void MethodA () {
try {
SavePoint

Serviceb.methodb (); propagation_nested level

} catch (Someexception) {
Perform other business, such as SERVICEC.METHODC ();

}
}

}
********************************************
That is, SERVICEB.METHODB failure rollback, then Servicea.methoda will also roll back to SavePoint point, Servicea.methoda can choose another branch, such as
SERVICEC.METHODC, go ahead and try to do your own business.
However, this transaction is not defined in the EJB standard.

Second, isolation level (transaction isolation):
1, Serializable: The strictest level, the transaction serial execution, the resource consumes the most;
2. Repeatable READ: Ensures that a transaction does not modify data that has been read by another transaction but not committed (rolled back). "Dirty reads" and "non-repeatable reads" are avoided, but more performance losses are incurred.
3. Read COMMITTED: The default transaction level for most mainstream databases ensures that one transaction does not read to another data that has been modified but not committed by a parallel transaction, avoiding "dirty reads". This level applies to most systems.
4, READ UNCOMMITTED: Ensure that the read process will not read illegal data. The isolation level is a concurrency problem that handles multiple transactions.
We know that parallelism can improve the throughput and efficiency of the database, but not all concurrent transactions can run concurrently, which requires viewing the serializable condition of the database textbook.
There is no elaboration here.
We'll start by talking about 3 things that might not be pleasing in the concurrency.
1:dirty reads--read dirty data. In other words, the uncommitted (and still cached) data for transaction A is read by transaction B, and if transaction a fails to roll back, the data read by transaction B is wrong.
2:non-repeatable reads--data cannot be read repeatedly. For example, the value of reading data-total-two places in transaction a. At the first reading, total is 100, then transaction b changes the total data to 200, and transaction a reads again, and the result is that total turns out to be 200, causing transaction a data chaos.
3:phantom reads--Phantom reads the data, which is similar to non-repeatable reads and is also a problem that is inconsistent with multiple reads in the same transaction. But non-repeatable reads is inconsistent because the data set he wants to take is changed (such as total data), but the inconsistency of the data that Phantom reads to read is not a change in the data set that he wants to read, but a change in his conditional data set. For example, select Account.id where account.name= "ppgogo*", the first time to read 6 eligible IDs, the second time, because transaction B to the name of an account from "DD" to Change to "Ppgogo1", As a result, 7 data were taken out. Dirty reads non-repeatable reads Phantom reads
Serializable not going to be
Repeatable READ will not be
READ COMMITTED will not be
Read UNCOMMITTED will be





Third, readOnly
The readonly flag in the transaction attribute indicates that the corresponding transaction should be optimized for read-only transactions.

This is one of the most optimized tips. In some cases, some transaction strategies can have a significant optimization effect, such as avoiding dirty checking (attempting to "refresh") when using the Object/relational mapping tool (such as Hibernate or TopLink).

D. Timeout

There is also an option to define a value of "timeout" in the transaction properties, specifying a transaction timeout of several seconds. In JTA, this is simply passed to the transaction coordinator of the Java EE server and is interpreted accordingly.

The propagation behavior and isolation level of spring transactions