MySQL transaction
Speaking affairs can not be separated ACID
-
Atomaticity atomicity
-
Consistency Consistency
-
Isolation Isolation
-
Durability persistence
-
Atomicity, we are more familiar. A typical example on bank transfers, the money can not be transferred to others, but no deduction on account! It may be that the blood loss!
-
Consistency know on almost an article about a very good article
-
Isolation is a matter between the multiple transactions, but also our topic today
-
Persistence, by definition, is fixed to the data on the hard disk.
But MySQL transactions are handled by the engine, InnoBD support.
Transaction isolation mechanism
Why have the transaction isolation
肯定是要有的
-
If there is only one database connection to operate the database, then really you do not need a transaction isolation level of!
- Of course, how could only one database connection does it !!!
-
Involves operations between multiple transactions, it must involve the isolation level of the transaction.
- Because it may operate the same data among multiple transactions. It is very possible problems!
I not only think, in Java thread safety issues. Singleton shared variable variable ...
Transaction isolation level
A said 级别, I started was confusing. I think this data is locked, so that the other can not modify the connection is not on line yet?
This can be, but is not necessary.
Because all simple process, it is thought that the consumption performance of low concurrency, high latency.
Hypothetically, if every transaction do so, the efficiency will be particularly low. Each thread had to wait a long time to execute sql.
It has a specific transaction isolation level which of it!
- Read Uncommitted: the lowest level of isolation, nothing needs to be done, a transaction can read the results of another uncommitted transactions. All problems will occur concurrent transactions.
- Read Committed: Only after the transaction is committed, it will update the results seen by other transactions. You can solve the problem of dirty read.
- Repeated Read: in one transaction, read the results for the same data is always the same, regardless of whether there are other matters to this data to operate, and whether the transaction commits. Can solve dirty reads, non-repeatable reads.
- Serialization: serialization transaction execution, isolation highest level, at the expense of concurrency system. You can solve all the problems of concurrent transactions.
Transaction isolation level, selected according to the needs of different business scenarios!
But long transaction will lead to great consumption performance.
commit work and chain
Impact of isolation level on the database
- Dirty Read: Transaction A modifies data, but did not submit the transaction to update the results of B read A uncommitted transactions, if the transaction fails to submit A, B transaction is read dirty data.
- Non-repeatable read: In the same transaction, inconsistent read results for the same data.
A B transaction before the transaction submitted to read the results, and the results may be different after the submission read.
The reason is the emergence of non-repeatable read transaction concurrency modify records, to avoid this situation,
the easiest way is to be modified record locking, lock this time leading to increased competition and affect performance.
Another method is by MVCC (multi-version concurrency control) can at no lock case, to avoid non-repeatable read. That is, the transaction level is repeatable read ...
- Magic Reading: In the same transaction, the same query repeatedly returned inconsistent results.
A new record of a transaction,
the transaction B before and after the transaction A submission to execute a query, time and again after the discovery of more than the previous record. Magic Reading is due to concurrent transactions increased due to record,
this is not like the non-repeatable read lock resolved by recording, because for the new record can not be locked. Transactions need to be serialized in order to avoid phantom reads.
We can each use different transaction levels to consider the values v1, v2, v3 of
- Read Uncommitted
- v1: v2 2: 2 v3: 2
- Read Committed
- v1: 1 v2: 2 v3: 2
- Repeatable Read
- v1: 1 v2: 1 v3: 2
- Serilazition
- v1: 1 v2: 1 v3: 2
spring affairs
Use the transaction in spring, there are 7 on the map. The most common, which is the default required.
spring has declarative transaction management (using annotations) and programmatic.
Which are more declarative, because this is simple and convenient. And do not affect the code logic, but must throw an exception!
But pay attention to the use of notes, must be added to the public and must approach throw RuntimeException (You can also specify the thrown exception);.
Once swallowed try catch an exception, then the transaction can not be rolled back!
I wrote an article for a moment I stepped on the record pit
In addition, if the company does not use transaction management provided by the spring, so be sure to ask how to handle the transaction. Do not take it for granted!
