A. Isolation Levels
When the operation data may bring . 3 side effect, are dirty reads, non-repeatable read, phantom read. To avoid this 3 occurrence of side effects, in a standard SQL statement defined . 4 isolation levels, it is read uncommitted, read committed, repeatable read, serializable. In the spring provides a transaction . 5 isolation levels to correspond to the SQL defined . 4 isolation levels, as follows:
| Isolation Levels |
significance |
| ISOLATION_DEFAULT |
Use the back-end database default isolation level |
| ISOLATION_READ_UNCOMMITTED |
It allows reading uncommitted data (corresponding to the uncommitted read), may result in dirty reads, non-repeatable read, phantom read |
| ISOLATION_READ_COMMITTED |
Another transaction has been allowed to read data in a submitted transaction (corresponding to Read Committed). Avoid dirty reads, but can not avoid non-repeatable read and phantom read |
| ISOLATION_REPEATABLE_READ |
Update a transaction can not be modified by another transaction but not yet committed (rollback) the data (corresponding to repeatable read). Avoid dirty reads and non-repeatable read, but can not prevent phantom read |
| ISOLATION_SERIALIZABLE |
Such isolation level is all transactions are executed in a queue, the order of execution order, rather than in parallel (corresponding serializable). Avoid dirty reads, non-repeatable read, phantom read. But this isolation level is inefficient, so unless necessary, otherwise it is not recommended. |
Read uncommitted read uncommitted
Next to Pharaoh particularly happy today, because today is his wife sent him this month's pocket money of the day, my wife told Pharaoh now making money, bank cards hit Pharaoh saw more than $ 500 a month would have been only 300, actually this month issued a 500, is coursing the occasion, the wife temporarily not think cart empty, then roll back the transaction, into a 300 and submitted. (Corresponding to what we call dirty read, two concurrent transactions, "Transaction A: Pharaoh sent his wife to pocket money", "Transaction B: Pharaoh check bank account", Transaction B reads the data transaction A has not yet submitted (500 yuan). when the isolation level is set to read uncommitted, it may appear dirty read, how to avoid dirty reads, see the next one isolation level).
Read committed Read Committed
Valentine's Day is coming, with a small three Wang went to a hotel, the front desk to see little sister system, the card balance display line 300, the Pharaoh is coursing occasion, at this time, my wife found enough money in the empty shopping cart , so the Pharaoh Cary $ 200 through online transfer to draw on their card and submitted, the system displays the Pharaoh submit the order found themselves amounted to $ 100, and then look at 300 bank card balance is not just the query but 100 yuan, a small three crashes break, angrily stormed away. (This corresponds to what we call the non-repeatable read, two concurrent transactions, "Transaction A: Pharaoh consumption", "Transaction B: Pharaoh's wife online transfer" Transaction A pre-read data, transaction B immediately update the data, and submitted to the transaction, the transaction a reads the data again, the data has changed. that is a read transaction a transaction data B has been submitted to another (here update), leading to the transaction a, inconsistencies in the results of multiple queries).
Sql Server, Oracle database default level is Read committed.
Repeatable read Repeatable read
Pharaoh angrily find a bank to discuss a statement, the counter will be Pharaoh's little sister bank card is set to change the next, to the Pharaoh said: "This is just great, once the banking system began to read the information on your card, other a man can modify the operation of the balance on the card (to solve the problem of non-repeatable reads) "Pharaoh dubious back home. Road, Pharaoh kept to a small three apologized and promised to turn now to a small three 100 yuan in the past as a way of apology, however, savvy wife at this moment is to see another bank bank card consumption on Pharaoh, Pharaoh recently found not in outside money with a bank card, thinking back to buy a la carte will be rewarding to cook what Pharaoh. Another Collage 100 yuan Pharaoh had to call a third, my wife and told Pharaoh counter will print about the water, but this time the water transfer money to strangers in the field of 100 yuan actually appeared, my wife a bit puzzled, that appear the illusion. (This corresponds to what we call repeatable read, or Part tale of two concurrent transactions, "Transaction A: Pharaoh consumption", "Transaction B: Pharaoh's wife online transfer" Transaction A pre-read data, B At this point the transaction can not update data and transactions a reads the data again, the data has not changed. repeat read solves the problem of non-repeatable read, but it is a problem phantom read, that a transaction (check water wife ) data read another transaction (Pharaoh transfer to a small three) that have been submitted (here insert, add a new table to the data), resulting in another transaction (wife check water), multiple queries in the transaction results inconsistent).
Mysql default isolation level is Repeatable read.
Serialization Serializable
After Pharaoh home, his wife asked out of some sort in the end this afternoon Pharaoh to whom transfer, Pharaoh dumb, thinking to himself, this I know that some sort of a transfer, does for me suspicious, should not, in order to prevent the case, then the next day go to the bank and the bank card upgrade, the counter told him: "well, upgrade, your card has the highest level of security, and when you transfer, did not turn before the finish others can not see your water. " This time Pharaoh relieved, but who knows little three long pull the black Pharaoh, and changed the phone number. (Serializable transaction isolation level is the highest, but the price is also the most expensive, low performance, rarely use, under that level, the branch order, not only to avoid dirty reads, non-repeatable read, but also to avoid the phantom read).
II. Read-only
If a transaction All operations on the database are read-only, that is to say, these operations only read data in the database, but does not update the data, then the transaction should be set to read-only mode ( READ_ONLY_MARKER ) , so more conducive to optimize the database .
Because the read-only optimization measures implemented after the transaction is initiated by the database, so that only those with a possible start of a new transaction propagation behavior (PROPAGATION_NESTED , PROPAGATION_REQUIRED , PROPAGATION_REQUIRED_NEW) transaction method is marked as read-only makes sense.
If you are using Hibernate as the persistence mechanism, then the transaction is marked as read-only, will Hibernate is flush mode is set to FULSH_NEVER, to tell the Hibernate avoid unnecessary synchronization between the database and all updates delayed until end of the transaction.
III. Transaction timeout
If a long-running transaction, then in order to avoid wasting system resources, this transaction should be to set a valid time to automatically roll back after waiting for a few seconds. & DESIGN
Set to " read only " attribute as the effective property transactions also need to have those transactions method might start something new propagation behavior of the marked read-only makes sense.
IV. The propagation of transaction boundaries are defined by the called method.
| Propagation behavior |
significance |
| PROPERGATION_MANDATORY |
Representation must be run in a transaction, if the transaction does not currently exist, an exception is thrown |
| PROPAGATION_NESTED |
He said that if the current transaction, then the method should be run in a nested transaction. Otherwise, it looks and PROPAGATION_REQUIRED looks nothing like two |
| PROPAGATION_NEVER |
Representation can not be run in a transaction, or an exception is thrown |
| PROPAGATION_NOT_SUPPORTED |
Representation can not run in a transaction, a transaction currently exists, then the method will be suspended |
| PROPAGATION_REQUIRED |
It indicates that the current method must run in a transaction, if there is a current transaction, then the method run in that transaction, otherwise, it creates a new transaction |
| PROPAGATION_REQUIRES_NEW |
It indicates that the current method must run its own affairs, if there is a current transaction, then the transaction will be suspended during the operation method |
| PROPAGATION_SUPPORTS |
It indicates that the current method is not required to run in a transaction, but if there is a transaction already exists, the method can also be run in that transaction |