SPRINGMVC transaction control and database isolation level

SPRINGMVC thing propagation and database isolation control

Http://www.cnblogs.com/yangy608/archive/2011/06/29/2093478.html

One, propagation (the propagation property of a transaction)

The Propagation: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: propagation_required--supports the current transaction and creates a new transaction if no transaction is currently in use. 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.

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.

Isolation level for spring transactions
 1. Isolation_default: This is a platfromtransactionmanager default isolation level that uses the default transaction isolation level of the database.
      Four additional isolation levels corresponding to JDBC
 2. Isolation_read_uncommitted: This is the lowest isolation level of a transaction, which allows a foreign transaction to see the uncommitted data for this transaction.
      This isolation level produces dirty reads, non-repeatable reads, and Phantom reads.
 3. Isolation_read_committed: Ensures that a transaction modified data is committed before it can be read by another transaction. Another transaction cannot read the uncommitted data of the transaction
 4. Isolation_repeatable_read: This transaction isolation level prevents dirty reads and cannot be read repeatedly. However, Phantom reads may occur.
      It ensures that one transaction cannot read the uncommitted data of another transaction, and that the following conditions are avoided (non-repeatable read).
 5. Isolation_serializable This is the most cost-effective, but most reliable, transaction isolation level. Transactions are processed for sequential execution. In addition to preventing dirty reads, the
      also avoids the illusion of reading, not repeating.

What is dirty data, dirty reading, non-repeatable reading, hallucination reading?
Dirty read: Refers to when a transaction is accessing the data, and the data has been modified, and this modification has not been committed to the database, at this time,
Another transaction accesses the data and then uses that data. Since this data is data that has not yet been submitted, another
The data that is read by a transaction is dirty, and the operation based on dirty data may not be correct.

Non-repeatable read: Refers to reading the same data multiple times within a transaction. When this transaction is not finished, another transaction accesses the same data.
Then, between the two read data in the first transaction, the data that was read two times by the first transaction because of the modification of the second transaction
May not be the same. This occurs when the data that is read two times within a transaction is not the same and is therefore called non-repeatable read.

Illusion reading: A phenomenon that occurs when a transaction is not executed independently, for example, when the first transaction modifies data in a table, this modification involves
To all rows of data in the table. At the same time, the second transaction modifies the data in the table by inserting a new row of data into the table. So
In the future, the user who operates the first transaction finds that there are no modified rows of data in the table, as if the illusion had occurred.

Database Isolation Level Control

This article is reproduced, the original address: http://singo107.iteye.com/blog/1175084

There are 4 isolation levels for database transactions, from low to high, READ UNCOMMITTED,Read Committed,Repeatable read, andSerializable, which can be resolved individually by each of the four levels Problems such as dirty reading, non-repetition reading, and Phantom reading.

√: May appear x: does not appear

	Dirty Read	Non-REPEATABLE READ	Phantom reading
Read UNCOMMITTED	√	√	√
Read committed	X	√	√
REPEATABLE READ	X	X	√
Serializable	X	X	X

Note: We discuss the isolation level scenario, mainly in the case of multiple transactions concurrency, so the next explanation is around the transaction concurrency.

READ UNCOMMITTED not submitted

The company paid, the leader of the 5000 yuan to the Singo account, but the transaction did not submit, and Singo just to check the account, found that the salary has been to the account, is 5000 yuan whole, very happy. Unfortunately, the leadership found that the amount of wages issued to Singo is not correct, is 2000 yuan, and then quickly rolled back to business, modify the amount, the transaction will be submitted, and finally singo the actual salary of only 2000 yuan, Singo empty joy a game.

The above situation, that is what we call dirty Read, two concurrent transactions, "transaction A: lead to Singo payroll", "Transaction B:singo query Payroll account", transaction B read the transaction A has not yet committed data.

When the isolation level is set to READ UNCOMMITTED, dirty reads can occur and how to avoid dirty reads, see the next isolation level.

Read Committed reading Commit

Singo take the payroll card to spend, the system read to Cary really have 2000 yuan, and at this time her wife also just in the online transfer, the Singo Pay card of 2000 yuan to another account, and before Singo submitted the business, when Singo deduction, System Check to Singo's payroll card has no money, deduction failure, Singo very puzzled, obviously card money, why ...

The above situation, that is what we call non-repeatable read, two concurrent transactions, "transaction A:singo consumption", "Transaction B:singo wife online transfer", transaction A in advance read the data, transaction B immediately updated the data, and committed the transaction, and transaction a read the data again, The data has changed.

When the isolation level is set to Read Committed, dirty reads are avoided, but may cause non-repeatable reads.

The default level for most databases is read committed, such as SQL Server, Oracle. To resolve the issue of non-repeatable reads, see the next isolation level.

REPEATABLE READ repeat

you can avoid non-repeatable reads when the isolation level is set to repeatable read. When Singo took the payroll card to spend, once the system began to read the Payroll card information (that is, the start of the transaction), Singo's wife could not change the record, that is Singo wife can not be transferred at this time.

Although repeatable read avoids non-repeatable reads, it is possible to have Phantom reads.

Singo's wife works in the banking department, and she often views Singo's credit card consumption records through the internal banking system. One day, she was inquiring into the total consumption amount of credit card in Singo month (select SUM (amount) from transaction where month = this month) was $80, and Singo at this time was good to eat outside the sea plug at the cashier to pay, spend 1000 yuan , which adds a $1000 consumption record (insert transaction ... ), and submitted a transaction, then Singo's wife will singo the current month credit card consumption details printed to A4 paper, but found that the total consumption of 1080 yuan, Singo wife is very surprised, thought there was an illusion, the illusion of such a generation.

Note: The default isolation level for MySQL is repeatable read.

Serialization of Serializable

Serializable is the highest transaction isolation level, with the highest cost and low performance, which is rarely used at this level, where the transaction sequence executes not only to avoid dirty reads, non-repeatable reads, but also to avoid Phantom reads.

http://blog.csdn.net/fg2006/article/details/6937413

SPRINGMVC transaction control and database isolation level